• Resolved Vernon Fowler

    (@vernonfowler)


    The switch direction feature is brilliant. I like that the control is site-wide and at least for our community do not foresee a need to have control at the group level. Nonetheless our community would truly benefit from adding an option for both up and down on this switch. That way activity from children would feed up to parent and grandparent groups and activity in highest level groups could feed down to child and grandchild groups. I assume this means that activity originating from mid-level groups would propagate both up to higher levels and down to lower levels. As currently designed, no desire for activity to propagate across to sibling groups.

    A 3rd option of both up & down would make this plugin an extremely valuable extension of BP Group Hierarchy. Please consider adding this option in the next iteration of Propagate. ??

    https://www.ads-software.com/plugins/bp-group-hierarchy-propagate/

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Author Christian Wach

    (@needle)

    Goodness me – I hadn’t even thought of that combined option, Vernon! Not too hard to implement, so I’ll add it into the next version.

    Cheers, Christian

    Thread Starter Vernon Fowler

    (@vernonfowler)

    Thanks Christian. Now I’m really looking forward to the next version. Also, glad to hear it is not too difficult to implement. ??

    By the way, your plugin was mentioned as one of my favourite 3 BuddyPress plugins in a lightning talk I gave at a WordPress Melbourne Meetup late last year.

    Cheers,
    Vernon

    Plugin Author Christian Wach

    (@needle)

    Sorry for being dense, but I’m trying to understand this “up & down” option… how does it help? If all groups in a hierarchy have all activity items, why have the hierarchy at all?

    Cheers, Christian

    Thread Starter Vernon Fowler

    (@vernonfowler)

    Hi Christian. Perhaps an example will clarify.

    Our BuddyPress installation forms the blended learning platform for several campuses of a language school. At the highest level of our hierarchy we have campus groups such as Melbourne and Sydney. Also at this level we have the 3 major streams: Academic, Business & General English. At the middle level of our hierarchy we have program specific groups such as the IELTS program and the University Bridging program (these belong to the academic stream). Then at the 3rd level we have class and cohort specific groups which are named according to the program of study, the chronological period and given an alphabetical naming for each class of 18students. Examples of these 3rd level group names would be “2A 139”, “18B 141” and “3C 142”.

    Students and staff may belong to any number of groups relevant to their work / study. Whilst students may have joined their class / cohort group they need to see activity from the parent and grandparent groups too. The program manager (who is only a member of the middle level groups) needs to broadcast messages down the hierarchy to all class / cohort groups. At the stream and campus level (top level groups) there is a need for the senior staff, program coordinators, and management to have both overview of all the child and grandchild groups and occasionally broadcast a message to all groups below without needing to belong to any of the groups down the hierarchy.

    In brief, activity messages flowing up and down a hierarchy is extremely useful so that members do not need to belong to groups that are not central to their roles but still receive information from related groups. Without activity propagating both up and down the hierarchy, broadcasting to child groups, monitoring and oversight of groups within a hierarchy is impossible. Right now we have 1/2 the functionality with unidirectional propagation – this is great but we’d love to see that potential explode with bidirectional. Hope that helps illustrate our scenario and need of this cool functionality.

    Cheers,
    Vernon

    Plugin Author Christian Wach

    (@needle)

    Interesting – thanks for sharing Vernon. Version 0.3 now has bi-directional propagation.

    You presumably know that the plugin recurses down hierarchies by checking if (a) the group is public or (b) the user is a member of the group. I don’t know if that has an impact on your scenario, but it seemed like the best policy to implement when I first wrote the plugin.

    Cheers, Christian

    Thread Starter Vernon Fowler

    (@vernonfowler)

    Thanks for all your work Christian.
    The check for (a) public groups – before propagating is perfectly reasonable but I need to ask is that both the originating group and the hierarchically related groups or just the former or latter?
    The check for (b) whether the user is a member of the group is interesting. By “user” do you mean the activity creating member? And by “is a member of the group” do you mean of the hierarchically related groups regardless of whether those groups are private or hidden?

    Most of our groups are public so I’m happy that this will work for the vast majority. We do have one hidden group and a small hierarchy of staff groups that are all set as private so I’m wondering what will happen in the general staff group and the child staff groups…

    Cheers,
    Vernon

    Plugin Author Christian Wach

    (@needle)

    By user, I mean the currently-logged-in user who is viewing the activity.

    This can get pretty complex, but say we’ve got one public top level group A with three child groups B, C & D which are public, private and hidden respectively. When I view the stream of group A, I see A’s stream, B’s stream (because it’s public) and C’s stream if I’m a member and D’s stream if I’m a member.

    If B, C & D also have three child groups, one of each type, I would definitely see A, B and B’s public child. I’d also see B’s private and hidden children if I’m a member of those groups.

    In addition, if (and only if) I’m a member of C, I’d see C’s stream plus C’s public child. I’d also see C’s private and hidden children if I’m a member of those groups. If I’m not a member of C, I would not see its stream, nor any of its children regardless of type. The same goes for hidden group D and its children.

    Some questionable cases, then, are scenarios like (a) where there are public child groups of private or hidden groups, (b) where there are groups I am a member of which are children of private or hidden groups that I do not belong to, (c) etc etc.

    Should the stream I see include those or not? Why would a private or hidden group have a public child group? And anyway, how would the breadcrumb trail display? I guess the answers depend on the setup of and intention behind the community.

    The two options at present are (a) stop recursing down the tree when the group is not public and I am not a member, and (b) keep recursing in case I find a child group which is public or which I am a member of.

    Thoughts?

    Cheers, Christian

    Thread Starter Vernon Fowler

    (@vernonfowler)

    When it comes to private groups, our structure – and the only one that makes sense to me – is that any children are also private.

    With hidden groups, we only have 1 or 2 groups and they are at the top level and standalone without children.

    I like the 2 options you present. Do (a) and (b) work simultaneously or have I misunderstood? If only 1 of (a) and (b) can operate, then (a) makes more sense to me. Otherwise, both (a) and (b) seem valid and ideal.

    Thanks again for your time on this.

    Cheers,
    Vernon

    Plugin Author Christian Wach

    (@needle)

    Sorry, I meant that options (a) and (b) are mutually exclusive. The plugin can do one or the other, but does (a) at present because that made most sense to me at the time. Sounds to me like the plugin’s working as you would expect it to. Marking as resolved ??

    Cheers, Christian

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Addition to switch direction’ is closed to new replies.