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

.
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.​

Title:
The default "Lot Item Permissions" is set wrongly to the least restrictive instead of the most restrictive.

Details:
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:
https://www.owasp.org/index.php/Security_by_Design_Principles#Establish_secure_defaults
"However, by default, the experience should be secure, and it should be up to the user to reduce their security – if they are allowed."

http://security-and-privacy-referen...docs.io/en/latest/08-security-principles.html
"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​

Title:
Switching between QA/Live resets to default values

Details:
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​

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

Details
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​

Title:
Inconsistent naming of "Lot Item Permissions" UI

Details:
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
Title:
Reproduction Rate:
Blocker?
Details:
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
SotA.EarlyAccess.QA.Win.64.660.Date.03.23.18
Area: OverworldIsland
Area Display Name: Hidden Vale
Loc: (242.5, -3.9, 145.0)
Debug: T3ZlcndvcmxkSXNsYW5kfHwoMjQyLjQ4NywgLTMuOTQ4LCAxNDUpfCgwLCAtMC44MiwgMCwgMC41NzIpfDI0OS43NjYxfDQ1fDI5