[Discussion] Permission dependencies

[halfdan]

I’m branching this off of #2739 as I think this deserves more discussion:

I am having trouble with the Notification permissions.

Once we have multi-user I think it is more than likely that apps would want to show persistent notifications (“Your article foo was published by $editor”). This would mean that notifications need to relate to a certain user. This user should then be allowed to delete the notification (so Admin + me).

Considering the “Please set up an email transport” notification on startup: A notification should only be shown for users in a certain role (in this case only for Admins) - an editor / author would not care about the notification (are they allowed to delete it though?).

I think a similar permission issue may arise with posts: Is an author allowed to delete his own posts (right now the answer is no)? What does an author do when he accidentally created a post - call an editor?

I think it would be beneficial to introduce a self permission for BREAD operations, meaning that I can execute those operations if I created the entity in question. A use-case for this might be for posts: An author cannot read posts unless they are his own.

---

Keeping in mind that at some point people will be able to change roles / permissions we should think about how permissions depend on one another: theme.edit uses theme.browse to validate that the theme that the user is trying to activate actually exists. If I were to create a new role where I allow a user to edit but not browse themes (because $reasons) it would break the theme.edit api method. A solution would be to move the { internal: true } we have introduced for the settings API up into the permissions check (how would the settings api know that it is allowed to touch core settings?).

[sebgie]

This is a 2 in 1 issue. Could we split them up?

I agree that we have a problem with permission dependency when it comes to users being allowed change roles themselves. The roles that are predefined now follow some rules that would have to be enforced when we allow users to edit permissions. For example if a role is allowed to browse() it also has the permission to read(). If a role has the permission to edit() it also has to have browse() and following the first example read().

I think a similar permission issue may arise with posts: Is an author allowed to delete his own posts (right now the answer is no)?

see #2264

[ErisDS]

Labelling all the open permissions related issues (there are several) with both permissions and later as I'm working on a spec to solve the immediate issues as well as a long term plan, which will replace all of these issues.