1. BibSonomy Avatar BibSonomy
  2. General
  3. BibSonomy

Wiki

Clone wiki

BibSonomy / development / features / Groups

View History

Umzug von Aktionen in die neue Architektur

Umzug der Gruppenadmin-Aktionen „Benutzer zur Gruppe hinzufügen“ und „Benutzer aus der Gruppe entfernen“

SettingsHandler -> JoinGroupController.\ Vergeben als Probearbeit\ Berücksichtige ggf. auch Verbesserungsvorschläge zur Gruppen-Account-Verwaltung/Mitgliederverwaltung

Verbesserungsvorschlage für das Gruppenkonzept

Veränderungen im Workflow rund um die Gruppen-Account-Verwaltung und Mitgliederverwaltung

Bei diesem Vorschlag soll die Usability verbessert werden. Die Gruppen-Erstellung wird sowohl für den Benutzer als auch für den Administrator vereinfacht. Der Gruppenbeitritt eines Mitgliedes wird vereinfacht.

Use-Cases

use cases

[A]= Administrator, [B] = normaler Benutzer, [G] = Gruppenadministrator

Gruppe erstellen

(Use-Case Bild 1)

  • [B] Gruppenantrag absenden: Der Benutzer sendet einen Antrag zum Umwandeln seines Accounts in einen Gruppenaccount ab. Bspw. Realisierbar durch eine Pending Groups Tabelle. Dies löst eine Emailbenachrichtigung an die Bibsonomy Admins aus.
  • [A] Gruppenanträge anzeigen: Der Administrator hat auf der Seite /admin/group eine Übersicht aller offener Gruppenanträge mit Link zum annehmen oder ablehnen.
  • [A] Gruppenantrag annehmen/ablehnen: Der Administrator kann den Gruppenantrag annehmen, wodurch die Gruppe erstellt wird und der Benutzer per Email benachrichtigt wird, dass sein Gruppenantrag angenommen wurde und die Gruppe erstellt wurde. Oder Gruppenantrag ablehnen mit einer kurzen Begründung, die dem Benutzer ebenfalls per Email zugestellt wird.
Mitgliederverwaltung einer Gruppe

(Use-Case Bild 2)

  • [G] Gruppeneinladungen absenden: Ein Gruppenadministrator kann Benutzern Einladungen zu seiner Gruppe schicken. Der Benutzer wird per Email darüber benachrichtigt.
  • [G] Gruppeneinladungen zurückziehen: Ein Gruppenadministrator kann offene Gruppeneinladungen wieder zurückziehen.
  • [B] Offene Gruppeneinladungen anzeigen: Ein Benutzer kann sich eine Übersicht der ihm geschickten Gruppeneinladungen anzeigen lassen. Mit Link zum Annehmen oder Ablehnen.
  • [B] Gruppeneinladungen annehmen/ablehnen: Der Benutzer hat die Möglichkeit eine Gruppeneinladung anzunehmen oder abzulehnen.
  • [B] Beitrittsgesuch abgeben: Ein Benutzer kann ein Beitrittsgesuch an eine Gruppe (Gruppenadministrator) abschicken. Optional wird der Gruppenadministrator zusätzlich per Email benachrichtigt.
  • [B] Beitrittsgesuch zurückziehen: Solange das Beitrittsgeruch nicht akzeptiert oder abgelehnt wurde, kann der Benutzer es wieder zurückziehen.
  • [G] Beitrittsgesuch annehmen/ablehnen: Der Gruppenadministrator kann ein Beitrittsgesuch annehmen oder mit einer optionalen Begründung ablehnen. Der Benutzer wird entsprechend per Email benachrichtigt.
  • [G] Gruppeneinladungen und Beitrittsgesuche anzeigen: Der Gruppenadministrator hat die Möglichkeit sich auf einer Übersichtsseite die Gruppeneinladungen und Beitrittsgesuche anzeigen zu lassen mit der Möglichkeit der oben besprochenen Aktionen.
  • [B] Gruppe verlassen: Der Benutzer kann eine Gruppe selbstständig verlassen.
  • [G] Benutzer entfernen: Ein Gruppenadministrator kann Mitglieder aus seiner Gruppe entfernen.

Datenbank Modell

Gruppe erstellen

group request table

#!sql

-- -----------------------------------------------------  -- Table `group_request`  -- -----------------------------------------------------  CREATE  TABLE IF NOT EXISTS `group_request` ( ``

`user_name` VARCHAR(30) NOT NULL , \`message\` VARCHAR(200) NULL , \`privlevel\` TINYINT(3) UNSIGNED NULL DEFAULT 1 , \`sharedDocuments\` TINYINT(1) NULL DEFAULT 0 , PRIMARY KEY (\`user\_name\`) , INDEX \`USER\` (\`user\_name\` ASC) , CONSTRAINT \`USER\` FOREIGN KEY (\`user\_name\` ) REFERENCES \`user\` (\`user\_name\` ) ON DELETE CASCADE ON UPDATE NO ACTION)
Mitgliederverwaltung

group request table

#!sql

-- -----------------------------------------------------  -- Table `join_group_request`  -- -----------------------------------------------------  CREATE  TABLE IF NOT EXISTS `join_group_request` ( ``

`user` VARCHAR(30) NOT NULL , `group` INT(10) NOT NULL , `reason` VARCHAR(200) NULL , `share_docs` TINYINT(1) NULL DEFAULT false , `time` TIMESTAMP NULL , PRIMARY KEY (`user`, `group`) , INDEX `USER` (`user` ASC) , INDEX `GROUP` (`group` ASC) , CONSTRAINT `USER` FOREIGN KEY (`user` ) REFERENCES `user` (`user_name` ) ON DELETE CASCADE ON UPDATE NO ACTION, CONSTRAINT `GROUP` FOREIGN KEY (`group` ) REFERENCES `groupids` (`group` ) ON DELETE CASCADE ON UPDATE NO ACTION)

COMMENT = 'This table represents join requests from a user to a group.';

-- ----------------------------------------------------- -- Table \`goup\_invitation\` -- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `goup_invitation\` (

`user` VARCHAR(30) NOT NULL , `group` INT(10) NOT NULL , `reason` VARCHAR(200) NULL , `time` TIMESTAMP NULL , PRIMARY KEY (`user`, `group`) , INDEX `USER` (`user` ASC) , INDEX `GROUP` (`group` ASC) , CONSTRAINT `USER` FOREIGN KEY (`user`) REFERENCES `user` (`user_name` ) ON DELETE CASCADE ON UPDATE NO ACTION, CONSTRAINT `GROUP` FOREIGN KEY (`group` ) REFERENCES `groupids` (`group` ) ON DELETE CASCADE ON UPDATE NO ACTION)

COMMENT = 'This table repesents the invitations that a group admin sent to an user.';

GUI Prototyp

Benutzer::Gruppenverwaltung

Entspricht den Tabellen 'join_group_request' und 'group_invitation' aus der Sicht eines Benutzers. group management user

Gruppenadmin::Mitgliederverwaltung

Wieder die neuen Tabellen, diesmal aus der Sicht eines Gruppenadmins group management user

Gruppenaccount:Antrag auf Umwandlung

group request gui

Sonstiges

Beachte ggf. auch Scheduling Problem

Attribut „Dokumente mit Gruppe Teilen“ für Gruppenmitgliedschaft eines Benutzers

Hier geht es darum, die Dokumente eines Benutzers besser zu schützen.

  • "groups"-Tabelle um Spalte vom Typ boolean erweitern. "share_docs"

  • Einige Anfragen anpassen

    • Unter /bibsonomy-database/src/main/resources/BibTex.xml:

      • "getBibTexForGroupWithPDF" außen um einen JOIN mit der "groups"-Tabelle erweitern
      • "getJustBibTexForGroupWithPDF"
      • "getBibTexForGroupByTagWithPDF"
      • "getJustBibTexForGroupByTagWithPDF"

    • Unter /bibsonomy-database/src/main/resources/Group.xml

      • "addUserToGroup". Hier ist zu beachten, dass "share_docs" durch den join request durchgeschleust werden muss. Daher wäre es sinnvoll, zunächst Änderungen der Mitgliederverwaltung zu implementieren, da sonst auf einen GET-Parameter zurückgegriffen werden muss, welchen der Gruppenadmin willkürlich verändern könnte.

  • Checkbox im Drop-Down-Menu "groups" oder auf Settings-Seite Tab "settings" für nachträgliches Einstellen. Oder kann auch in der Sidebar auf der Gruppenseite untergebracht werden. Beachte, dass die Checkbox an der gleichen Stelle untergebracht werden sollte, wo ein Benutzer die Gruppe auch verlassen kann, vgl. Änderungen der Mitgliederverwaltung.

  • Auf "Join group"-Formularseite Checkbox für initiales Einstellen

Admin/Moderatoren-Rechte an mehrere Mitglieder einer Gruppe vergeben

  • Hauptaccount kann auf Groupsettingsseite Hilfsadmins ernennen und herabsetzen.

  • Für Hilfsadmins muss neue Seite geschaffen werden. Es muss berücksichtigt werden, dass ein Nutzer in mehreren Gruppen Hilfsadmin sein kann.

    • Ein Hauptadmin kann Hilfsadmin in anderen Gruppen sein, ansonsten müsste dies ausgeschlossen werden. Daher sollte die Groupsettings-Seite angepasst werden. Aktionen die auch ein Hilfsadmin ausführen kann, sollten auf der Seite für Hilfsadmins untergebracht werden.

  • Hilfsadmins können gruppeneigene Beiträge ändern bzw. anlegen. (Gruppeneigene Beiträge sind Beiträge, die dem Gruppenaccount gehören)

Datenbank

Es wird 'user_status' in der Tabelle 'groups' verwendet

  • '0' steht dabei für Gruppenadmin
  • '7' steht für ein reguläres Mitglied.

GUI

TODO: Alle Listen mit Usern mit Suchleiste versehen, und Anzahl Treffer zur Auswahl anbieten.

Gruppenaccount::Settings

frame

Gruppenadministrator-Seite

frame

Benutzerlisten verbessern

Bspw. auf der Seite für Gruppenadmins werden vollständige Benutzerlisten für eine Gruppe benötigt, bspw. um einen Benutzer aus einer Gruppe zu entfernen. Diese Listen sind bisher wenig übersichtlich, sobald viele Benutzer angezeigt werden. Daher wäre es schön, eine spezielle Liste zu haben, die eine Variable Anzahl an Nutzern pro Seite anzeigt, aber auch eine Textsuche ermöglicht. Evtl. könnte man die Liste lexikografisch sortieren. So könnte die Benutzerliste aussehen, hier am Beispiel aus der Seite für Gruppenadministratoren

Möglichkeit für Gruppenadmin Gruppen-Tagsets per UI zu verwalten

(auf Settings Seite, berücksichtige ggf. Punkt 2)

  • Aktionen „Anlegen“, „Verändern“ und „Entfernen“.

  • Evtl. Vorhandene Formulare zur Bearbeitung verwenden.

  • Attribut „zwingend“ anlegen.

    • Im EditPost-Dialog durch JavaScript forcieren

Weitere Ideen

Untergruppenbeziehungen zwischen Gruppen (Hierarchie)

  • Einer Gruppe gehören zusätzlich alle Beiträge und Mitglieder an, die einer ihrer Untergruppen angehören

    • Beschränkungen für Beiträge nach oben

  • Beiträge nach unten denkbar.

Probleme

Scheduling Problem beim Erstellen einer Gruppe

Gefunden in /bibsonomy-database/src/main/resources/Group.xml:

<select id="getNewGroupId" resultClass="int"> SELECT MAX(`group`) + 1 AS id FROM groupids </select>

Vorsicht, falls zwei Admins gleichzeitig Gruppenanträge bearbeiten können.

Updated