[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