Replies: 1 comment
-
If you wanted to stick to giving permissions based on tags, you would either need to move the relevant tags higher up the chain to a read-only entity (e.g. put the tag on the site which will be read-only to the end user, but grant read/write permissions to models underneath constrained to said tag), or create a tag custom field with the read-only/hidden flag (meaning it can only be changed via API, and then restrict API write permissions). The flexibility of permissions is all or nothing at the model level, so individual fields cannot be restricted unless of course they are actually related models. With that said, the system is extremely flexible as is, and might even be too flexible leading to some complexity for some use cases, or just a bit more planning on how best to tackle it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I can't figure out how to make restrictions correctly. I created several sites (cities), each with its own set of devices, ip addresses, vlans, etc. I created groups for reading and writing for each site, and now I'm thinking how flexibly I can assign permissions, I tried to do it through tag {"tags__name": "Tag_site1"} and this tag I assigned all the entities in the site, it helped, the group with its tag saw only its site, but additionally I had to give permission to the tag tab because without this, users could not add or edit anything on their site. Is this correct? maybe there is some better way? where can I even read about naming in Constraints, "tags__name" or "site__slug" is it possible to somehow see the entire list that can be used?
Beta Was this translation helpful? Give feedback.
All reactions