Bonfire
Bonfire copied to clipboard
Permissions Cleanup
I am looking at paring down the permissions that exist in the system at the moment. My thought is to do one of the two following things:
- Each module gets a single permission by default. Custom modules can create more, but instead of Bonfire.Activities.View, Bonfire.Activities.Edit, etc, we simply have Bonfire.Activities.Manage.
- We provide 2 for each module: Bonfire.x.View and Bonfire.x.Manage.
@svision @mwhitneysdsu @sourcejedi What do you guys think?
Will paring this down at this time cause the existing apps you manage to break or can we get away with something like this?
I can probably deal with view/manage on my end, but the single permission would probably be a problem. I'm pretty sure the cases in which I actually use all 4 are in custom modules anyway.
That said, I don't really understand the desire to reduce the permissions in this way. While the interface for managing permissions for the core would improve, it would still get out of hand for users with more than a handful of modules. The UI is the real issue here, not the number of permissions. On Jun 2, 2013 10:39 PM, "Lonnie Ezell" [email protected] wrote:
I am looking at paring down the permissions that exist in the system at the moment. My thought is to do one of the two following things:
- Each module gets a single permission by default. Custom modules can create more, but instead of Bonfire.Activities.View, Bonfire.Activities.Edit, etc, we simply have Bonfire.Activities.Manage.
- We provide 2 for each module: Bonfire.x.View and Bonfire.x.Manage.
@svision @mwhitneysdsu https://github.com/mwhitneysdsu @sourcejedihttps://github.com/sourcejediWhat do you guys think?
Will paring this down at this time cause the existing apps you manage to break or can we get away with something like this?
— Reply to this email directly or view it on GitHubhttps://github.com/ci-bonfire/Bonfire/issues/826 .
And I'm completely open for better UI ideas, but as it stands we have 50 permissions by default and I think the vast majority of them are never used in the 90% of the sites that get made with Bonfire. I obviously don't have any data that way, but most of the sites I've dealt with if someone can manage something, that includes editing, deleting, etc. It's been an extremely rare case where someone was given edit rights but not delete rights.
With basic CMS functionality in place with pages, categories, blog posts, possible ecommerce products, FAQ, etc. the number of permissions can easily reach 100-150 or more, which becomes a small bit of a nightmare to ensure that every role has the correct permission.
Now, perhaps a UI overhaul could make that more manageable, I'm not sure, but it seems like a bigger hassle than is needed in most cases. When someone does need more, they can add them in and tweak the code for that site. I think it's rare enough that, for the core functionality that Bonfire ships with, anyway, we can strip it down to improve the end-user's experience, who may or may not be super technical and can easily get overwhelmed with the process. Granted, we would hope that whoever is assigning the permissions to roles would know what they're doing, but that's not always the case.
But that's why I'm checking with the rest of the team. I'm not sure that my experience with the system necessarily represents everyone's experiences.
Oops - meant to bring in @svizion but spelled your handle incorrectly!
I understand the basic reasoning, it's just that at this point my Permissions List is 24 pages long and my Permission Matrix scrolls in both directions even in full screen. Cutting the default permissions in half (which isn't quite the case with just Manage/View, since we have other permissions, too) or even to 1/3 or so isn't really addressing the issue, just limiting the default contribution to the issue and reducing the functionality of the permission system.
Additionally, the Bonfire.* permissions currently only have 2 permissions or fewer per core module with the exception of the Roles and Users modules (and an additional 8 Activities.* permissions for the Activities module). So, I guess I'm really only losing something with Users and Roles (though I would note the Bonfire.Modules.* permissions are Add/Delete), and I think both of those areas need some revisiting anyway (Bonfire.Roles.Add and Bonfire.Roles.New? I remember there being some kind of reason for that, but I'm not sure what it was).
When I first started using Bonfire, I liked the Permission Matrix. It's a novel idea that works well for a very small list of roles and permissions. However, I think the numbers at which it becomes less manageable (i.e. 20 or so permissions and maybe 10 roles) are too small for us to realistically expect to maintain. The titles on the checkboxes make it usable at any size (since hovering over the checkbox gives you the role and permission), but the matrix loses most of its advantages once you start scrolling.
One thought is to roll up Module-level permissions with checkboxes checked if the user has one or more permissions selected for that module (and checking/unchecking the box would add all/clear all permissions for that module), allowing the user to expand each module to view the individual permissions as needed (maybe with an expand/collapse all button as well).
Another would be to make the table heading fixed and only scroll the table body.
Of course, that's just one area where you view the permissions. Even the list of permissions for a given role, especially Administrator, can be an issue. I usually just use the browser's find command and start working my way through it. Even if nothing else is done, the permissions need to be sorted on this view.
It would probably also be useful to have a list of Roles with a given permission when you view the Edit Permission page. Instead we just link the user the Permission Matrix again, and, since it's in a different module, change the navigation on them if they go to the matrix from the Permissions module.
I'm sure I'll have something else to contribute once I really give it some thought. I think there are a few low-hanging fruit, such as sorting the permissions, that may be more helpful than removing many of the default permissions.
I kinda think the matrix needs a way to only show permissions for 1 context or 1 module, so you can go through and adjust them. It's been a long time since I looked the permissions matrix but I know it's a mess when you get a lot of permissions in it.
Seems to me it would be better to add a filter on them then remove more and break backwards compatibility since all the module builder coded modules use .Edit .Delete, etc all over the place. Would break anything built before the module builder was updated.
I have been thinking of a UI for this that might help. I enjoy the concept of having permissions based on CRUD (create, view, edit, delete), but of course this potentially creates a permissions matrix from hell if you have a ton of modules.
Since the naming convention is typically
For instance, if I want to view all "Bonfire" permissions, I simply type "Bonfire" and I get them all in a list. Same goes for "Site" or "Content." If I find someone was able to create something in the database that they shouldn't have been able to, then I could search "Create" and look through all of the associated modules to find the culprit. If I know the issue affects a particular module, I can search that modules' name... or chain them if I'm looking for something specific.
It wouldn't be that hard to come up with a UI for this and I'd be happy to help develop it if we think it's a good idea.
P.S. Sorry I'm late to the convo. Just found this little bugger and I'm excited!
I think a UI change for it would definitely be helpful. And the search element would be a great addition to the Matrix. Would love to see a pull request for that. :)
It's just a thought, because I'm pretty swamped at the moment, but I wonder if the jQuery DataTables plugin would work to add a search function to the matrix...
@mwhitneysdsu, it most certainly would! I don't know why this didn't pop into my head, I'm working on a site that uses this right now. Let me take a bit more of a look into it and see if I can't get something together in pull request form.