Wedge
Public area => The Pub => Plugins => Topic started by: Arantor on October 23rd, 2011, 10:24 PM
-
This is sort of plugin related and it more directly affects plugins than it does anything else, I guess.
I think one of the current paradigms in SMF is wrong, that permissions should intrinsically be added to the permissions page - when it just doesn't make sense to do that sometimes.
I lost count a long time ago of the number of threads of people asking about things like nneonneo's shoutbox and asking how to set it so people see the shoutbox. Of course, the answer is to set permissions - but when permissions are set somewhere else from any configuration/settings that the shoutbox might have, it's illogical.
Ironically, SMF also features one method to actually deal with this, though most people don't realise it.
When I split the calendar out, as I will be doing shortly, I don't have to rework the permissions too much - because the UI of the calendar settings actually has an inline permissions facility, where you can set access by group (which feeds into the permissions system natively) to different calendar features, just as you can with general permissions.
Weirdly, though, it never really hit home to me until tonight just how broken the paradigm is. I dug out an old SMF 1.1.x test site, and decided to play around with the chess mod. It's pretty neat actually. But you have the Admin > Chess Admin area with Settings and Maintenance pages - then you have to go elsewhere for the permissions, and it jolted me when I had to get out there and reset it myself.
Had the permissions been inlined into the config pages, I wouldn't have had to look and no doubt had I been a newbie, I'd have been way more confused.
It makes me wonder though. When I get round to ripping permissions out and replacing them, do I actively need to consider putting roles in, with directly extensible support (like we have now), or is it actually better to bar plugins from touching the core permissions and making them put permissions in their own settings pages? (Obviously, provide facilities for doing this, SMF 2.0 and Wedge do actually do some of this, though it needs expanding to cope with _own/_any and non-general/context-specific permissions, as right now only general permissions can be dropped in easily)
I'm just thinking that simple plugins only need a permission or two and can trivially pull that in, complex plugins need something bigger but might as well get a dedicated section for it in their own admin area, without having to clutter up the core permissions - and it means that we don't have to worry about making it extensible on a UI level, and more importantly, plugins get to keep their facilities all under the one roof.
At least, that's how it is in my head. Would love to know what others think.
-
If a plugin can house it's own permissions in it's own settings/acp that would be great. I've had that noob issue where I installed a mod dealt with all the settings, thought it wasnt working only to realize it added permissions. Even the small mods I think could/should add their own permission or preferably at least a link to the permissions page from within its' acp if it's adding the permissions there; that would just make life a whole lot easier. The way SD/WD houses it's own permissions should be the model for the larger more complex plugins.
On a side but somewhat related note I even believe the general permissions should be split off from the Default board permissions.
-
SD/WD didn't really have a lot of choice in terms of doing things, and now I look back, I'm amazed I was satisfied with 1.0 doing what it did, because it made a mess of the permissions page by adding a screen's worth of permissions, not to mention that it did confuse people by being somewhere other than where all the settings were. But by the time we got beyond 1.0's release, we pretty much *had* to roll out the newer permissions simply because they just didn't work in SMF's setup.
Right now though, I'm in the state of mind where I don't want to craft something that's acceptable, as it were, but to set forth the way it *should* be done. I'm not sure that just linking to a plugin's permissions is that useful from the plugin itself when for a similar amount of programming effort it can actually create that permission UI inline. (Adding permissions in a plugin, assuming it's using the standard template is a one line affair)
On the flip side, I can see the value of providing it in both places when you create a new membergroup/role/whatever. There it actually makes some kind of sense - but not a lot, when it still would likely be better putting it per-plugin, in the long run.
From where I'm standing, having a plugin integrate into the central permissions is actually more illogical, overall, than it being in the plugin area, especially since people are more likely to add new plugins than they are - generally - to add new member groups, and if they do add new member groups/roles/whatever, the odds are they're doing it for specific permissions anyway, so it's even more important to get it right.
As far as SD/WD's model goes, I'd pretty much provide the framework to larger plugins to be able to do that with the minimum of hassle. I still find it ridiculous that all the large mods all had to roll their own permissions framework because the core couldn't accommodate it, when there's no reason why a single framework couldn't cope with everything SD, Aeva and PT (just to name three) generally needed as far as permissions were concerned.
-
Permissions should split up like the Modification setting page, allow each mod to add it's own and have a common misc. page for everything else. That way it gets easier, and the page needs to have a host of customizability options otherwise mods like AeMe would fail to be fully incorporated into the permission area. Just a question, are you only planning on overhauling the permissions UI or the underlying structure as well?
-
AeMe is the high end-- and it's not even a plugin by now ;)
-
Permissions should split up like the Modification setting page, allow each mod to add it's own and have a common misc. page for everything else.
That does exactly the same thing: a plugin that adds a single permission is going to look out of place, as is a plugin that adds a massive permission area. In both cases, it still doesn't solve the disjoint where users have to go to multiple places to configure things - if a plugin is adding its own area already, it is flat out illogical to have to make users go elsewhere to configure permissions separately.Just a question, are you only planning on overhauling the permissions UI or the underlying structure as well?
-
That's not what I meant, I didn't mean that it should split out into multiple pages exactly like the mod settings page, I meant that it should be divided into such areas each individually accessible via the permissions page and each should show permissions related to only that with one common area for a setting or two.
-
That's not what I meant, I didn't mean that it should split out into multiple pages exactly like the mod settings page
I meant that it should be divided into such areas each individually accessible via the permissions page and each should show permissions related to only that with one common area for a setting or two.
This is why I'm debating not making it easy to add permissions directly to the main permissions areas and instead making plugins do it themselves. (For general non-own/any permissions, there's a 'permissions' field type for setupDBSettingsContext.)
-
Fair enough, but that'd spread out permissions to even more areas causing more confusion, wouldn't it?
-
I don't think it would, though that's really the point of this topic.
See, I'm not just talking hypothetically at this point. Firstly, the Chess mod confused me... to see it having a settings page and not discovering the permissions are elsewhere actually stumped me for a moment. (Not any more than that, it wasn't hard for me to figure out that's what I was supposed to do - but it did confuse a lot of users.)
Secondly, I reflected on SimpleDesk. SD's permissions are huge, which is why it has its own dialogue and setup - and it made me realise that instead of being confusing, it actually isn't, because it puts that plugin's permissions with everything else for that plugin.
SMF even does that - check out the calendar settings page. Right there, it puts the permissions into the calendar area, though it is configurable from the main permissions area too. But even there it feels more logical to go to the calendar page to set who can see said calendar....
-
Okay, that does sound kind of logical to me. How about adding links to those areas in the actual permissions tab? So that users looking for permissions can go there directly.
Also, all these permissions would run through a central permission control(As in would all the permissions be stored in a single area) or would that be also completely up to the mod author?
-
Okay, that does sound kind of logical to me. How about adding links to those areas in the actual permissions tab? So that users looking for permissions can go there directly.
Also, all these permissions would run through a central permission control(As in would all the permissions be stored in a single area) or would that be also completely up to the mod author?
-
OK, I don't think I'm making myself clear here. Why would I add a link from a plugin to the permissions area when for a similar amount of effort, I can *just put the permissions in the plugin area*? Unless you're talking about a link from the main plugins front page to the permissions area, which seems a lot of effort for a relatively small gain.
Um... centrally since it's already partly built and everything I've said has been about extending what's already there?
-
Coming at this in reverse (Devil's advocate...) could the permissions page (as an over-arching concept) be removed entirely, and permissions spread to where they would otherwise make most sense (Board permissions live with Boards, etc...)?
Get rid of the "permissions page" mentality... Does that fix/break anything else?
-
Interesting idea, I hadn't actually considered going that far.
Of course the argument I presented above against my own POV gets clobbered even more: create a new group and you then have to update its permissions in a whole bunch of places rather than a few (or one, on an unmodified, unexpanded forum)
Also that would require expanding things in places that currently don't have GUIs for them - for example viewing Who's Online only has an option or two buried elsewhere in the admin panel, though it only has one permission attached. Same deal with the member list.
Board level permissions are a bit trickier, due to the fact it isn't only permissions in that board, but it's permissions in that board by user group (though, arguably, no different to what would happen if pushed totally into the plugin's area to cope with)
-
I wouldn't get rid of the permissions page but we could add internal links. Just make an icon that suggests 'internal admin alias' and add links anywhere it makes sense. Including in the plugin list when a plugin is enabled. It should have aliases to any page it modifies or hooks into.
-
I still don't get why there's a need to provide a link from one place to another when the setting on the other page is on the page you're putting the link in...
-
Hmmm, curious. I knew that the inline permissions setup wasn't able to handle any/own, and that it was possible to set exclusions (like permissions that shouldn't be possible to give to guests) but I didn't realise that the exclusion was per page, not per permission.
Might have to fix that, since I want to set up a settings page with three permissions, one that should be open to any users, one that should be non-guest groups, and one that should be non guest, non regular member groups. (i.e. general access, slightly restricted and administrative type)
-
I'm confused here as to what you are saying here. Do you mean to allow mods to have their own separate permissions page in their ACP if they want, but otherwise keeping the smaller mods inside of the normal permission page?
Since there's no doubt going to be more of smaller add-ons than larger ones there's going to be less of a need for, let's say a BBC mod, to have a separate area for permissions. However for add-ons that do require their own settings area it would make sense that the permissions would be there instead of taking up the permissions page.
It depends on the mod, I suppose. It doesn't seem to be the kind of feature where you can have it one way or the other.
-
Argh.
Already, without writing a single line of extra code, permissions can be set for specific features outside the permissions area.
Grab an SMF forum. Doesn't matter what version (though if it's 2.0, be sure to turn the calendar on), then go to the calendar settings. In there, there is a collection of permissions for the calendar.
You don't even have to revisit the permissions page to set them, you just configure the calendar right there, its settings and its permissions.
Now imagine that the calendar is a plugin. It will be eventually but right now that's hypothetical. Anyway, the calendar is a plugin, you enable it, an icon appears in the Plugins area in the ACP (menu included), where all the settings are.
My central point is that if you are defining a page in the admin for something, why is there a need to put part of its configuration in one place and part in another? Especially when it is not immediately obvious what is going on and causes so many questions for users.
This lead me to wonder if, in fact, it would be better not to allow the main permissions to be directly configurable and force plugins to contain all their permissions in their own configuration area.
There are not that many cases where a plugin would add a permission and no other settings whatsoever, in fact I can only think of about 3 cases I've seen where it would come up and even then, it still requires more work than just setting up a permission anyway.
I would note that plugins having their own permissions/settings area is not unheard of, nor is it unheard of to force them to do that. WordPress operates on that sort of principle, as does iOS, and for good reason.
-
You have my approval either way ;)
-
I like the idea of plugins having there own permissions page. The only time that might be a drag is if one adds a new group or something down the line. How ever that is rare, Maybe a link on the (core) permissions page to the (each) plugins permissions page to make it slightly easier.
-
I like the idea of plugins having there own permissions page
The only time that might be a drag is if one adds a new group or something down the line. How ever that is rare
Maybe a link on the (core) permissions page to the (each) plugins permissions page to make it slightly easier.
-
I honestly can't think of a less effective way to do it, to the point where not providing a link would almost be better. Since it would require each plugin indicating its permissions UI to the core UI (and we all know how badly mod authors generally do at 'doing any more work than they absolutely have to'), I might as well just encourage them not to bridge the two like that, and instead just have them integrate permissions into the core UI through the normal fashion. No point reinventing the wheel like that.
EDIT: added four extra words that make it even more clear what the thought experiment expectation is.
-
And yeah, that's what I suspected you were getting at. Just that for some things right now that isn't practical. But it does make for interesting thoughts about how some things should work.