always add current user to acl #389
Conversation
|
Shouldn't this also be added to |
| read: true, | ||
| write: true, | ||
| actions: [], | ||
| }); | ||
|
|
||
| setFormikFieldValue("policies", template); | ||
| setFormikFieldValue("template", templateId); |
There was a problem hiding this comment.
In app/src/components/events/partials/ModalTabsAndPages/NewAccessPage.tsx we do check the ACLs with await dispatch(checkAcls(formik.values.acls));. Shouldn't we do this here too?
There was a problem hiding this comment.
Dont know, but better make an own issue for that and stick to this issues topic?
No, when creating a user the user gets his own role in any case, even when no role was selected. Not sure where this happens, maybe in the backend? |
|
This pull request has conflicts ☹ |
|
Hei @ziegenberg, could you have another look into this pr? Would be cool if we could get this to the next release since this is kind of crucial for our oc setup |
|
Would an admin be able to select an ACL template without being in the list as the current user? |
Selecting a template would always add your user to the list, but you can off course delete that entry. |
There was a problem hiding this comment.
Works and makes sense to me.
I agree that this does not need to be added to app/src/components/users/partials/wizard/AclAccessPage.tsx. Unlike for events or series, ACL templates have no sense of ownership, meaning users don't need their role in the template to edit it.
|
I'm ok with the change, as it adds feature parity with the old Admin UI. For later reference: This kind of business logic should ideally be placed in the backend and not the frontend. So we do not have to implement this kind of logic in all interfaces again. |
Closes #385