Gruppenbesitzer sollten nicht unbedingt Gruppenmitglieder sein

On my site I have a use case for people being given the privilege of managing group membership without being a member of the group themselves. I assumed this is how it worked and was surprised to see that someone I added as group manager is now also a group member.

The use case? We use groups to assign badges. And to give access to private categories. And the people responsible for doing this are not always group members.

Edit: having noticed this, I then removed some group owners only to realize they are still group members. Seems to me these should be managed independently.

15 „Gefällt mir“

We ran into this problem this week, too. (Although our groups represent a “group” membership outside of Discourse, too.) But that membership is not decided by a member of the group, and not by a Discourse admin, either.

5 „Gefällt mir“

Just ran into this very problem, where a group’s membership is not administered by a member of the group.

Our use case

We want a handful of non-Discourse-admins to be able to manage group membership for several groups without becoming members of those groups themselves.

Extra credit

This is probably asking too much, but I thought I’d throw it in… it’d be awesome if a group could be named as admin of another group (i.e., membership of the @bar group can be managed by any member of the @foo group). This would allow us to have a “group managers” group containing our non-Discourse-admins in charge of managing other groups’ memberships. :slightly_smiling:

5 „Gefällt mir“

I just moved this to the #feature:voting category as I’d like it to be thrown into the mix for voting when that starts happening.

I like this idea! There is one person in charge of managing internal groups in my community but does not need to have admin privileges. It would be helpful to be able to set up a group for this so we can easily add/remove people to help her.

Another related feature that would be needed is the ability for group owners to see and manage the group even when “Group is visible to all users” is deselected. There should also be the option to allow group members, or members of a specific other group, to see the group.

1 „Gefällt mir“

Sure, I am open to disconnecting the two permissions.

7 „Gefällt mir“

Any chance the goal of “group owner does not need to be group member” with stretch goal of “group can be named as owner of another group” would be suitable for a GSoC project?

2 „Gefällt mir“

Very unlikely, way too small of a job.

Group can be owner of another group is not even something I would be comfortable adding.

Did anything come from the OPs request to separate group membership & group ownership? @sam supported the idea a while back (above).

Scenario: We added a moderator to a group, to manage group membership. However, this resulted in him getting the group’s badge displayed on his avatar.

3 „Gefällt mir“

Thanks for the reply, @Biscuit! I just came across this again in my community and the issue persists. In fact, it’s becoming a bit of a problem because certain leaders in my community complain that they are not trusted to properly manage the groups they are charged with managing. They have to ask an admin to add/remove people. I’m trying to keep down the number of admins (a conversation for another day).

It’s pr-welcome so the discourse team have indicated they are open to having it done as a community contribution. Any takers?

It appears to me that with the new front-end groups management interface, there is no obvious place to list owners who are not members. Perhaps the answer is simply to just list them at the top, with the Owner badge but not the date added, posted or seen. And/or to list with a highlight color, as on staff posts?

Then the functionality to add owners could be a + ADD OWNERS button next to the existing + ADD MEMBERS button. Selecting this would pop up a modal to add one or more owners. On the list, if the REMOVE MEMBER button is selected and the member is an owner, the user would remain on the list as an owner but not as a member. If REMOVE AS OWNER is selected, the user would remain as a member but no longer as an owner (unless the user is not already a member and was only listed as an owner, in which case the user would be removed from the list entirely).

Unannotated screenshot for illustration.

5 „Gefällt mir“

We have the use case that there should be one master group that manages many smaller groups (~30 / i.e. @Archangels manage local Angel communities). They should not have to be members of all 30 groups, just be able to add/remove members.

3 „Gefällt mir“

We also run into this each time Google Summer of Code comes around. It also seems related to the various ideas about hierarchical/sub-groups, too.

3 „Gefällt mir“

Ja, hallo, ich habe dieses Problem auch und werde Ihnen ein Beispiel für die Fragen geben, die es aufwirft und die etwas ärgerlich sind. Als Gruppen-Ersteller und -Besitzer muss es einen Standard-Gruppenmanager geben, und das bin ich, der Administrator, und ich kann niemand anderen ernennen. Denn es gibt keinen Grund, warum diese Person eine Gruppe verwalten sollte, die ich selbst erstellt habe. Es sollte Gruppenmitglieder und einen Gruppenadministrator geben, aber der Administrator muss meiner Meinung nach nicht automatisch Mitglied dieser Gruppe sein. Hier ist das Problem, das sich in meinem Fall ergibt.

Ich verwende das Plugin für die Expertenkategorie. Daher habe ich bestimmten Kategorien eine Gruppe von Experten zugewiesen. Leider werde ich automatisch als Experte in dieser Gruppe betrachtet, was überhaupt nicht gut ist, denn wenn ich ein neues Thema poste, heißt es, dass ich als Experte beitrage, obwohl ich überhaupt kein Experte für das Thema dieser Gruppe bin. Nun, ich weiß nicht, ob ich mich klar ausdrücke. :grin:

Hallo Patrick! Obwohl ich immer noch denke, dass diese Feature-Anfrage legitim ist, bin ich mir nicht sicher, ob ich Ihren Anwendungsfall verstehe.

Sind Gruppenbesitzer durch das Expert Category-Plugin erforderlich? Andernfalls ist es möglich, Gruppen ohne Besitzer zu erstellen.

Sie benötigen Gruppenbesitzer für die Funktion, mit der Benutzer die Mitgliedschaft in der Gruppe beantragen können.

Ich denke, das ergibt Sinn, da Benutzer die Mitgliedschaft beantragen müssen und nicht eigenmächtig entscheiden, dass sie Experten sind. Sie machen doch etwas Ähnliches mit der @support-explorers-Gruppe, oder?

@patrickemin Ich habe letztes Jahr einen Fehler gemeldet, der Ihnen helfen könnte, nicht als Mitglied der Gruppe hinzugefügt zu werden. Aber Sie müssten einen Arbeitsablauf finden, um häufig zu prüfen, ob es neue Anfragen im Anfragereiter der Gruppe gibt, da Sie in diesem Fall keine Nachrichten erhalten.
Aber es ist möglich, sich nach der Aktivierung von Mitgliedschaftsanfragen selbst aus der Gruppe zu entfernen:

4 „Gefällt mir“

Danke @moin! Ich bin immer wieder beeindruckt, wie gut du dich mit Discourse auskennst. :clap:

Ich habe gerade über die Begründung nachgedacht, warum ein Gruppenbesitzer für die Einstellung „Benutzern erlauben, Mitgliedschaftsanfragen zu senden“ erforderlich ist, und das ergibt für mich Sinn. Man möchte nicht in einer Situation sein, in der alle Moderatoren benachrichtigt werden müssen, wenn jemand einer Gruppe beitreten möchte. Daher möchte man in diesem Fall auch, dass es möglich ist, dass der Gruppenbesitzer kein Mitglied der Gruppe ist.

4 „Gefällt mir“

Meiner Meinung nach wäre eine ziemlich einfache Lösung, dass Anfragen zum Beitritt zu einer Gruppe nicht nur an den Gruppenbesitzer, falls vorhanden, sondern auch an den Administrator gesendet werden. Auf diese Weise würde der Administrator, wenn es keinen Gruppenbesitzer gibt, trotzdem benachrichtigt werden und müsste weder der Gruppenbesitzer noch ein Mitglied der Gruppe sein.

Eine gute Option wäre, eine Gruppe als Eigentümer zuzulassen. Dies würde gestufte Gruppen mit einer Hierarchie ermöglichen, anstatt nur Eigentümer/Mitglieder zu haben, wie Sie es kennen, wenn Sie eine Gruppe als Eigentümer hinzufügen – Administratoren, Eigentümer und Mitglieder. Eine Einschränkung könnte jedoch sein, verwaltete Gruppenkategorien/-zugriffe zu erben, da diese technisch gesehen in beiden Gruppen vorhanden sind.

Ich möchte die Funktion „Massenhaft Besitzer hinzufügen“ untersuchen, vielleicht finden Institutionen sie nützlich.

Wenn ich auf dieses Thema zurückblicke, stelle ich fest, dass die Auswahl einer Gruppe für die Massenaufnahme möglicherweise nicht optimal ist.

Vielleicht wäre es schlecht, wenn dies synchronisiert würde, und es wäre vielleicht schwierig, Ursache und Wirkung zu erkennen.

Nun, wir haben bereits eine Art Gruppenbesitzer mit Kategorie-Moderatoren. Ich mache so etwas manuell.

Die Möglichkeit, dass eine Gruppe eine andere Gruppe verwalten kann, bedeutet, dass Besitzer einfacher hinzugefügt/entfernt werden können, ohne dass ein Administrator erforderlich ist. Da die Gruppe der Gruppenbesitzer ihre eigenen Kernbesitzer hat, die reguläre Mitglieder in der Besitzergruppe hinzufügen/entfernen können.

Danke Dan — dein Punkt, dass Kategorie-Moderatoren eine Gruppe besitzen können, die mit ihrer Kategorie verknüpft ist, kommt sehr gut an. Es scheint, als ob du dir eine flexiblere Admin-Struktur vorstellst, bei der eine Gruppe eine andere Gruppe verwalten kann — und das könnte bei der Optimierung von Berechtigungen und Arbeitsabläufen sehr hilfreich sein.

Derzeit erlaubt Discourse nur einzelnen Benutzern, Gruppenbesitzer zu sein. Aber in realen Anwendungsfällen, insbesondere in strukturierten Communities (wie Schulen, Abteilungen oder Teams), möchten wir oft sagen:

  • „Gruppe A (z. B. mentor-coordinators) kann Gruppe B (z. B. mentors) verwalten“
  • „…ohne dass Mitglieder von A zu B hinzugefügt werden oder dessen Auszeichnung/Identität erben“

Das würde ermöglichen:

  • Klare Trennung zwischen Identität (Gruppenmitgliedschaft) und Kontrolle (Gruppenbesitz)
  • Delegation der Mitgliederverwaltung (einladen/entfernen/genehmigen) ohne sitewide Admin- oder Moderatorenzugriff
  • Die Möglichkeit, die Moderation einer Kategorie an die Gruppe zu binden, die ihre Posting-Gruppe kontrolliert

Es scheint, als ob du auf ein Modell hinweist, bei dem der Gruppenbesitz nicht nur Benutzernamen, sondern auch andere Gruppen akzeptiert. Diese Idee deckt sich mit einigen älteren Threads:

Ich wäre neugierig, wie du dir das vorstellen würdest:

  • Würde die Benutzeroberfläche die Besitzvererbung anzeigen, wenn ich in der verwaltenden Gruppe bin?
  • Sollte der Gruppenbesitzer alle Gruppeneinstellungen bearbeiten dürfen oder nur die Mitglieder verwalten?
  • Könnte dies mit Kategorieberechtigungen gekoppelt oder automatisch mit der Kategorie einer Gruppe verknüpft werden?

Unterstütze die Idee auf jeden Fall — ich würde mich freuen, wenn diese weiterentwickelt wird.

2 „Gefällt mir“