Search the Community
Showing results for tags 'permissions'.
I feel that the RDMS and Assets lists hark back to the first days where every player had a maximum of about 17 constructs and an org had a maximum of <300... its far too clunky for dozen+ or hundred+ cores. RDMS and Assets (Constructs and Territories) lists need to be leveraged here to maximise their benefits. DOCUMENTATION The RDMS policy rights are poorly documented with a single line of text for each. Much better documentation with examples is needed... Game is still in alpha, but we need to start somewhere. UI RDMS screen needs to have a clear list of all rights pertaining to the policy on a single, non-scrolling display and use CHECKBOXES to enable and disable the rights. Remove the UNORDERED dropdown list of active policies and replace it with the single screen above. When you check or uncheck a right, it changes colour to show that it is being altered and a simple press of OK or Cancel should determine application or not. Management requires the ability to retrieve information rapidly and clearly All lists need to be filterable by location, type, size etc. so we know how many and where they are. Linking in the RDMS to the system map would be amazing, so we can see our assets on the map and drill down. Allow assets ASSETS RDMS Needs to be include POLICY, ACTOR, ASSET, TAG, where Asset means all constructs and territories. Currently there is somehow NO ASSET TAB in the RDMS and we are still unable to assign or even view our constructs or territories tags from the RDMS manager. NQ might want to allow the RDMS manager to list all the constructs and territories and assign the constructs to policies within the RDMS directly without having to visit the construct manually and add a tag to it. TOKENIZED TAGGING Currently there are no Key Cards or Token access right now. There should be an asset class that when picked up or bought from a dispenser applies a tag to the holder The token times out after a certain period or condition or can be cancelled by the RDMS owner. Player retrieves or buys a token from a dispenser or receives one from an org member. The player then has the tag or tags applied to him for the duration of the token's existence. Removes the need to manually add and remove players from the RDBMs to access assets temporarily. This is perfect for guests, visitor days or test drives etc. DATABASE RELATIONSHIPS Leverage the DB. Everything is relationally linked, use those links to help the RDMS manager. Currently, if you click on a policy, it shows what tags and actors apply. Expand this: View a list of all players that have rights in the RDMS. Click on a player to see what Actors they belong to and what policies they are part of. Click on an actor to see what policies they are part of. Click on a tag to see what policies its used in and what assets its tied to Click on an asset to see what tags are assigned and what policies its used in. Click on an asset and reveal it in the map. DENIAL / EXCEPTION / INHERITANCE The RDMS has currently no way to deny or create exceptions. This means that additional policies are sometimes needed for subtle differences in access. Add a tag to an element to REMOVE a particular right... for example #NoNoobs We might want to temporarily deny certain rights in one policy without influencing a whole cluster of other policies or recreating groups from the ground up. Exceptions are essential here, like denying ALTs access to certain key assets. This can also be useful in panic situation where a quick response is needed. Just deny first and work out the details later. While constructs have the ability to remove inheritance from their parents, the RDMS does not have this. If you assign a right to a construct, everything ON THAT CONSTRUCT also inherits the right automatically. Setting inheritance to only certain assets on a construct would be useful for example: Public use extends only to furnature types but not combat types or containers. FOLDERS, TAGS and ACTORS Tags and to a lesser extent Actor groups have been shown to be more flexible but ultimately harder to manage and more importantly KEEP ORGANISED than simpler folder/directory structures. Give players the ability to group constructs logically in folders and allow application of RDMS to folders and subfolders. Give players the ability to group players logically in folders and allow application of RDMS to folders and subfolders. The RDMS manager can then create folders such as public assets, high security, private etc. https://asistdl.onlinelibrary.wiley.com/doi/pdf/10.1002/meet.2008.1450450214#:~:text=Tagging permits a many-to,accessed again later by either. here is an (oldish) research paper discussing the relative merits of folders and tags and came to the conclusion that having both is better than either since we all work and think differently. ORG RANKS This is linked to the above ACTORS section: There are only currently three org ranks formally defined. Superlegate, Legate and Member. The Member part needs to be expanded to allow additional, org defined roles with more granularity than just MEMBER. Rank policies assigned by rank. TESTING There is currently no method to test any policies RDMS cascading rights viewer is needed Because cascading or inheriting rights from multiple policies is possible, we need to be able to select a construct or player from the RDMS list and view EXACTLY what rights are active or denied. Much like the CSS viewers on any modern browser that show all the applicable CSS attributes from all the cascading rules. Or the Windows active directory permissions viewer which shows actual and inherited rights. Effect Viewer If we change a policy, we need to see exactly what actors and assets will be influenced If we can match a player or actor to an asset and see exactly that that actor/player can or cannot do, it would save a lot of heartache. Construct overview We need to be able to select a construct and see who has what rights and more importantly, VIEW ANY RDMS tags that have been applied to elements on that construct. It's all too easy to overlook a container hub with public rights or a dispenser that is only available to legates. Element rights viewer At a construct level, we need to be able to right click any element and view EXACTLY what rights pertain to that element including inherited rights from the parent construct. ADDITIONAL RDMS needs to include asset visibility right to allow non legates to view constructs on their maps. Why is this important? NEVER FORGET MARKETPLACE 15!
So I just read up about how territory is going to work, and how the force field idea is implemented, and it got me thinking: Will there be/is there, a more in depth system of permission setting then just allowing or not allowing someone access? I would suggest we have options like "tagging" all, but for organizations once implemented in game. Also, I drop down menu based UI would be welcome, though the current one seems to work fine from the Dev footage. This drop down based system could be per "tag" (an individual, all, organization, etc), and have a default setting. I'd like to hear any other ideas other people have about this, because sharing rights can be a tedious things sometimes. Any other "tags" like the "all" "tag", are especially invited, because I'm more interested in those mechanics at least to start with.