Supporting Structured Permissions

[myleshyson]

Our team is currently creating our own Calendar module module because we need a nested calendar system and currently there's nothing out there that supports that.

One of the features we're wanting to support is the ability to add permissions for a user to manage a parent calendar, and then whenever a child calendar is added, automatically make it so that same user has permissions on the child.

Right now the permissions setup is not very supportive of a tree structured system. Yes you can add nested permissions, but those permissions are only available whenever a parent permission is selected. The problem with that is, say we have a structure like this:

• College Of Medicine Calendar
  • Department of Neurology Calendar

If we wanted to give a user only the ability to manage Department of Neurology, that's not currently possible, since you would first have to check College of Medicine.

Now you may look at that and think "can't you just have a flat list of calendars?" We can, however there are two problems with that approach.

1. It's a nightmare to manage for our QA person. We're going to have 100's of calendars in this system, so having to manage a flat list of calendars is not ideal.
2. There's still the problem of assigning permissions automatically. Even if our QA person assigns someone to "College of Medicine", and then down the road another department requests a calendar, "Department of Epidemiology", the college of medicine user still won't automatically get assigned to the epidemiology calendar.

After working this week on it, I can see a few solutions to this in the short term:

1. The main thing that would help is adding a hook on the craft\elements\User::can method or the craft\services\UserPermissions::doesUserHavePermission method. This would allow us to code our own logic for when a user can or cannot access a calendar without having to actually assign nested permissions to users.
2. Separate the EVENT_REGISTER_USER_PERMISSIONS event from what's displayed in the permissions tab. Currently whatever is registered is automatically displayed. However, in trying to come up with my own logic I realized pretty quick that I couldn't use Craft's permission system AND not display permissions in the permissions tab. If an event is added on User::can, and the logic between registering and displaying permissions was separated, then we would be able to have our own system for permissions (like a users field on calendars), utilizing core craft functionality, without the confusion of those permissions showing up in the permissions tab.

Admittedly our use case is pretty complex, but I think could benefit the CMS overall by adding flexibility.

Let me know what ya'll think about this!

[brandonkelly]

How exactly are you implementing the calendars? Is this a custom element type?

[myleshyson]

Yep the calendars are a custom element type. I'm using the following architecture:

• Calendar Group --- A model that acts like a structure for Calendars. There can be multiple calendar groups. Very similar to Section or CategoryGroup
• Calendar --- A custom craft element, with it's structure id being the Calendar Group it belongs to
• Event --- A custom craft element, with a Calendar field allowing it to belong to multiple calendars.

[brandonkelly]

Is this for Craft 4, and are you taking advantage of the new unified element editor? If so, you can put whatever authorization logic you want into your Calendar class’ canView() and canSave() methods, including factoring in who created the parent calendar, etc. You don’t need every single element to have its own permission, etc.

[myleshyson]

You know what, I'm just now realizing my thinking about it as been a little too rigid 😅 . Yea you're totally right, those element permission functions are the only thing I need. Thanks.