You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I can tell, the permissions system is purely role-based. For example, if I have a role which gives me the EditMeetingComment permission, then I am capable of editing all meeting comments.
Say a meeting comment should only be editable by the one who made the comment (or to add some complication, it could also be edited by a sysadmin). What would be a good way of extending the project?
Perhaps something like adding ACLs to the User access controller? It's not clear to me when permissions would be added/changed/removed - always at the controller level, or in integration events? I think the latter case could require that you pass around the identity of the user to the actions and events, which seems not ideal.
Any ideas on how to implement this? (Or is it already there and I've totally missed it)
The text was updated successfully, but these errors were encountered:
Ah ok upon further digging I see that these are encoded as rules inside the aggregates - the Meetings domain has IMember context which accesses the user id from the IExecutionContextAccessor, and then checks that e.g. the current user is also the one who authored the comment. So mystery solved I guess.
I still wonder how this would work with the case I mentioned where a comment can be edited by either the author or a sysadmin. Or maybe a comment might also be edited by some trigger that's not caused by a user via the API, rather a Cron job or something.
As far as I can tell, the permissions system is purely role-based. For example, if I have a role which gives me the
EditMeetingComment
permission, then I am capable of editing all meeting comments.Say a meeting comment should only be editable by the one who made the comment (or to add some complication, it could also be edited by a sysadmin). What would be a good way of extending the project?
Perhaps something like adding ACLs to the User access controller? It's not clear to me when permissions would be added/changed/removed - always at the controller level, or in integration events? I think the latter case could require that you pass around the identity of the user to the actions and events, which seems not ideal.
Any ideas on how to implement this? (Or is it already there and I've totally missed it)
The text was updated successfully, but these errors were encountered: