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.
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.