Permission based view on server settings#1482
Conversation
| [SerializeField] private List<GameObject> _defaultObjects; | ||
| [SerializeField] private List<RoleView> _roleViews; |
|
I think having one role and one view per PermissionBasedView component would be more foolproof and comprehensible later. For example, PermissionBasedView component on (administrator) would enable it only when permission>=Administrator; PermissionBasedView component on (default) would enable it only when permission<Administrator. This way there is less interaction between objects and we won't need to research context to find what exactly disables/enables the object we are focused on in the future. Or at least we could have one role and a list of default and role views per component. |
removed the DisableIfNotAdmin object as it's no longer used |
iamteapot422
left a comment
There was a problem hiding this comment.
Right references, but methods aren't specified


Summary
The server settings view was getting destroyed when you're not an admin and was obviously not readded after the permission is automatically added, leaving the whole panel empty on the first run of the game in the editor.
To fix this, rather than destroying the object we're gracefully handling the lack of permissions with a separate view that just says permission denied. The code for the button now checks permissions too for completeness sake.
The new behaviour that enables or disables objects based on permission is intended for UI use and simply has a list of permissions and their associated objects. All matching permission's objects are enabled, the default is disabled. If no permissions match, the default is enabled.
PR checklist
Pictures/Videos
Testing
Changes
Related issues/PRs