[buddypress-trac] [BuddyPress] #2673: Plugins Management for Groups
buddypress-trac
noreply at wordpress.org
Sat Sep 7 21:28:54 UTC 2013
#2673: Plugins Management for Groups
-------------------------------------------------+------------------
Reporter: michaelha | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 1.9
Component: Groups | Version:
Severity: normal | Resolution:
Keywords: has-patch 2nd-opinion needs-testing |
-------------------------------------------------+------------------
Comment (by imath):
Replying to [comment:4 boonebgorges]:
> - I would have created a front-end UI for group admins to toggle
extensions. To my mind, the real power of this functionality is to let
group admins have it.
I agree at 100%, but i guess i didn't think about this as for instance i
always add an option in my plugins to deactivate/activate the plugin for
the group from the group front-end admin ui. But you're right some plugins
may not allow the group admin to deactivate them.
> - I would have left out the global defaults. They're a bit confusing: as
imath wrote the patch, they provide global fallback settings. But they're
just fallbacks - there's no way to force an extension toggle across all
groups.
My goal wasn't really to toggle, i wanted to find a way to let the
superadmin making globally unavailable plugins group extensions or simply
leave them available. So when a plugin is deactivated, i guess the verb i
use in the group extension management is confusing for restoring the group
extensions as available. So "Activate" should be replaced by the idea
"make it activable by group admins"
>So, it seems to me like it's of limited use, especially given that we're
adding an entire admin panel for it. A more fleshed out version of the
admin panel would do a bit more: it would allow super admins to set the
*default* value for each extension, and it would let the admin toggle
whether group admins would have granular control over that given
extension's toggle.(This is how xprofile field visibility works: admins
can set a default level, and can also say whether individuals can modify
it.) IMHO, it's only worth adding this panel if we provide this kind of
rich functionality. If it's just for fallbacks, the same thing can be done
with filters.
In 2673.diff, the super admin was able to globally deactivate a group
extension, and from the group backend admin UI force the group extension
to be active even if it was globally deactivated. I thought that a super
admin might want to restrict some group extension to some groups. That's
why my groupmeta was an array of group extension statuses ( e.g.
buddydrive => 1, forum => 0..)
I've noticed in 2673.02.patch that you changed this behavior by only
saving the inactive group extensions which breaks in a way my first logic,
because if in the group back-end admin UI we can only deactivate, then the
global setting can't be override for the group by the super admin.
(PS : there was also a fatal error as you refer to a function of my first
patch but don't include it in yours :( )
So in 2673.03.diff, i benefit from your great work - i agree mine was a
bit ugly, i like fishing ;) - and restore to my first idea :
1/ Super Admin has a global power on Group Extensions : he can leave them
do their job or neutralize some of them
2/ If a group extension is globally neutralized, Super admin can still
activate it from the group back-end admin UI for the groups he wants.
And i agree a front end UI could give us a third point :
3/ group admins from the group front end UI can deactivate a group
extension that is left available (globally > point 1/ or not point 2/)
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/2673#comment:5>
BuddyPress <http://buddypress.org/>
BuddyPress
More information about the buddypress-trac
mailing list