1. We have a QA initiative where we work with the community more closely than ever to get your bug reports into the hands of the developers. Please use this forum for LIVE Server bug reporting. Do follow the format below, because it will help us out greatly in responding. If you do not, it's possible your bug report will be misinterpreted, or worse, lost!

    Read BEFORE submitting your first bug: Reporting Bugs… QA 101 Document
    • Search for your bug before posting in order to avoid duplicate reports.
    • Only reply to an existing thread if you have additional information for the reported bug. ALL extraneous commentary will be deleted to avoid cluttering the reports.
    • Keep your bug report short and factual.
    • There is no need to submit crash logs. Crash data we require is automatically logged.
    Bug Report Template
    1. Title:
    2. Reproduction Rate:
    3. Blocker?
    4. Details:
    5. Steps to Reproduce:
    6. User Specs:
    To get started, use /bug in-game (/devbug if on QA) to auto-create this template. It will even auto-fill some of the required information and open the browser for you. Then take the information that was just saved to your system's clipboard and paste it into a new QA forum post. Thank you bug hunters!
Dismiss Notice
This Section is READ ONLY - All Posts Are Archived

Two bugs in one - Switching to/from QA sets your deco placements to Kindred

Discussion in 'Player Owned Towns & Player Housing' started by Spoon, Mar 26, 2018.

  1. Spoon

    Spoon Bug Brigade - Bug Hunter

    Likes Received:
    Trophy Points:
    So this is not a new behavior, but I've never seen it responded to nor Jirad. It also in that the combo of these bugs creates a trap for users of QA.

    Where the issue is getting more and more grave the more users we have that help out testing in QA.

    Bug 1.

    The default "Lot Item Permissions" is set wrongly to the least restrictive instead of the most restrictive.
    In the pic you can see the Default values for "Lot Item Permissions" - they are set by Default to Kindred.
    This goes against established software security principles, in that the software should protect the user.

    The fix is easy - any and all default values regarding permission/security should of coure always be set to the highest possible security and it should then be up to the user to lower them if they so see fit.
    (Which in this case would be Co-Owner on everything, and both place and move items).

    For instance:
    "However, by default, the experience should be secure, and it should be up to the user to reduce their security – if they are allowed."

    "In computing systems, the save default is generally “no access” so that the system must specifically grant access to resources."

    It also goes against ISO etc.

    Now, yes I know all of the software standards above does not normally goes for content within games. However not using such sound basic security principles on the basis that "this is just a game" would be rather counter productive when large part of the business model relies on items of significant monetary value.

    Bug 2 - which is what makes the above such a VERY VERY BAD design principle to miss​

    Switching between QA/Live resets to default values

    When a user switches between QA/Live, then the settings reset to Default.
    In combination with the Bug 1 above then that means that switching to/from QA will reset all default back to "Kindred". So if you don't know about both bugs you might place something which you think is secure (Co-owner) but instead isn't (Kindred).
    Which in combination with the current Guild permission/Charter house is a recipe for disaster.

    This means that after each QA testing when I'm back on Live I need to reset my Permission settings to what I need them to be.
    Where if the default was the highest security this would not be as big of a problem.

    Bug 3 - or rather feedback​

    Lot Item Permission UI does not have a "save/commit/apply"

    Lot Item Permission UI does not have a "save/commit/apply" or any system feedback to the user that the new default behavior has been set. This means that the user has to try it out to see whether or not the changes works as intended and/or was applied correctly.
    Making something which should give a feeling of security, instead give a feeling of uncertainty.

    Bug 4

    Inconsistent naming of "Lot Item Permissions" UI

    The naming of the ways to open "Lot Item Permissions" has inconsistent texts.
    It is also missing the key word "Default" which is the whole point of the window setting in question.

    The top right menu icon says "Item Permissions"

    The right click context menu says "Permission Options"

    BUT the window UI title says "Lot Item Permissions"
    Where the term "lot" adds no info and the term "Default" which is the key term is only mentioned in passing in extra small font.

    Since it is missing to display that Default term loudly enough then lots of users that I've talked to have thought the window would apply to the "selected" object - ie you right click an object and set the "Item Permissions" but in reality nothing changed on the object you right clicked since the only thing you changed is the Default behavior for next time.

    Proposed Fix:
    All three should be renamed into:
    "Default Item Permission Settings" or if short is needed then "Default Item Settings" since the permission bit can be infered

    3/26/2018 12:26 PM
    Reproduction Rate:
    Steps to Reproduce:
    User Specs:
    OS: Windows 10 (10.0.0) 64bit
    CPU: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (8) System RAM: 16296
    GPU: NVIDIA GeForce GTX 860M GPU RAM: 4064
    Area: OverworldIsland
    Area Display Name: Hidden Vale
    Loc: (242.5, -3.9, 145.0)
    Debug: T3ZlcndvcmxkSXNsYW5kfHwoMjQyLjQ4NywgLTMuOTQ4LCAxNDUpfCgwLCAtMC44MiwgMCwgMC41NzIpfDI0OS43NjYxfDQ1fDI5
    Rentier likes this.