< Datenschutz Konfiguration | Admin-Dokumentation | Rund um Benutzer >

Seminarklassen und Seminartypen

verfügbar ab Stud.IP-Version 2.4.0

Als Root angemeldet kann man unter Globale Einstellungen -> Seminarklassen differenzierte Einstellungen für Seminarklassen und Seminartypen vornehmen. Diese Änderungen betreffen ganze Teile von Stud.IP und sollte daher vorsichtig vorgenommen werden. Dennoch sind alle Änderungen jeweils rückgängig machbar und betreffen nur die Datenbank. Im Zweifelsfall kann man Änderungen also schnell wieder rückgängig machen, Im Notfall auch durch ein Datenbank-Backup.

1.  Konzept der Seminarklassen und Seminartypen

Jede Veranstaltung in Stud.IP ist einem Seminartypen zugeordnet und jeder Seminartyp einer Seminarklasse. Man könnte also auch sagen, jede Veranstaltung ist genau einer Seminarklasse zugeordnet. Jede.

Seminarklassen können das Erscheinungsbild, die Art, wie eine Veranstaltung erstellt oder verwaltet wird, komplett verändern. Studentische Arbeitsgruppen haben zum Beispiel eine ganz andere Verwaltungsseite als alle anderen Veranstaltungen. Sie tauchen auch im normalen Veranstaltungsassistenten nicht auf. Veranstaltungen der Organisation zum Beispiel werden nicht im Studienbereichsbaum eingehängt. Das alles sind Parameter der Seminarklassen. Dass die eine Veranstaltung sich also so verhält und die andere etwas anders, wird hauptsächlich über die Seminarklassen geregelt.

Alle Logik geht dabei auf die Seminarklassen zurück. Die Seminartypen bilden mehr oder weniger eine Unterkategorie, die nur beschreibenden Charakter hat. Für das Erscheinungsbild der Veranstaltung sind die Seminartypen daher unerheblich. Allein die Seminarklassen machen die Suppe salzig.

2.  Aufbau der GUI zum Bearbeiten der Seminarklassen

Ist man auf der Seite der Seminarklassenadministration angekommen, sieht man alle Seminarklassen untereinander geschrieben in einer Tabelle mit der zusätzlichen Angabe der ID (meistens unwichtig) und der Anzahl der zugeordneten Veranstaltungen. Klickt man auf eine Seminarklasse, kommt man zur entsprechenden Seite, um die Seminarklasse zu bearbeiten. Alle Änderungen werden erst wirksam, wenn man unten auf der Seite auf "speichern" klickt.

3.  Parameter einer Seminarklasse

3.1  Titel von Dozenten, Tutoren, Autoren

Man kann für eine Seminarklasse definieren, wie Dozenten darin genannt werden sollen. Das hat den Hintergrund, dass in den meisten Vorlesungen einer Uni die Dozenten auch Dozenten genannt werden. In einer Organisationsveranstaltung will man sie aber vielleicht viel eher "Organisatoren" nennen oder "Bereichsleiter" oder was ganz anderes. Bei studentischen Arbeitsgruppen heißen die Dozenten beispielsweise "Gruppengründer".

Hier kann man diese Titel leicht ändern. Zu jedem Titel (Dozent/Tutor/Autor) kann man entweder den Systemdefault auswählen oder man gibt explizit die Singularform und Pluralform des Titels an. Das erste Feld ist die Singularform (z.B. "GruppengründerIn") und das zweite die Pluralform (z.B. "GruppengründerInnen"). Beachten Sie, auch die Auswahlbox am Anfang der Zeile auf den richtigen Wert zu setzen. Wenn die auf "Systemdefault" steht, werden die eingegebenen Titel trotzdem ignoriert.

Was ist dieser Systemdefault? In den meisten Installationen von Stud.IP wird ein Dozent auch Dozent genannt werden, ohne dass man das immer neu angeben muss bei allen Seminarklassen. Wenn Sie den Systemdefault auswählen als Titel, werden die Dozenten immer so heißen, wie in den meisten anderen Veranstaltungen im System. Falls Sie den Systemdefault selbst ändern wollen, sollten Sie das nicht hier in jeder Seminarklasse, sondern in der Datei config/config.inc.php und der Variable $DEFAULT_TITLE_FOR_STATUS tun.

3.2  Inhaltselemente und Modulslots

Inhaltselemente einer Veranstaltung sind gleichbedeutend mit den Reitern, die man in einer Veranstaltung sieht. Das wären das Forum, der Dateibereich, Plugins wie DoIt oder Evaluationsplugins, aber theoretisch sogar die Übersichtsseite oder die Verwaltungsseite.

Der Dozent oder Admin kennt das von der Verwaltungsunterseite "Inhaltselemente", manchmal auch Plus-Seite genannt. Dort kann er/sie einstellen, welche Inhaltselemente in der Veranstaltung aktiviert sind. Übersichtsseite und Verwaltungsseite sind ihm da vermutlich noch nie über den Weg gelaufen. Das liegt daran, dass in den Seminarklassen (in den allermeisten Fällen) definiert ist, dass die Übersichtsseite nicht deaktiviert werden kann, ebensowenig wie die Verwaltungsseite. Wäre auch seltsam. Aber, und das müssen Sie sich vor Augen halten: theoretisch geht das.

Die Einstellungen der Inhaltselemente für Seminarklassen ist dominant zu den Einstellungen des Dozenten auf der Plus-Seite (nur noch übertroffen von globalen Einstellungen $wiki_enable, das Inhaltselemente bzw. deren Slots komplett deaktivieren kann). Was der Dozent wegen der Einstellungen der Seminarklasse gar nicht einstellen kann, wird ihm/ihr am Ende auch gar nicht mehr angezeigt. Was man nicht weiß, macht einen nicht heiß.

Nun zu den Modulslots. Eine Veranstaltung hat 12 Modulslots, wovon jeder Slot mit maximal einem Inhaltselement bzw. Modul gefüllt sein kann. Was ein Slot genau ist, weiß ein Dozent oder Admin nicht und muss er/sie auch gar nicht wissen. Für den Dozenten ist nur der Workflow wichtig "ich deaktiviere jetzt das Forum". Welches Modul genau hinter dem Forum steckt, ob das Kernforum oder ein Plugin als Forum, ist dem Dozenten egal und kann er auch nicht beeinflussen. Beeinflussen können nur Sie das und nur auf dieser Seite. In den meisten Fällen steckt im Slot "Forum" das Kernforum, wie wir es alle kennen. Sie können das aber auch entfernen und dann ein Plugin als neues Forum für diese Seminarklasse definieren.

Die Zuordnung von Modulen und Slots geschieht durch Drag&Drop. Ziehen Sie also das Modul "Kern-Forum" vom Slot "Forum" in den Bereich "Nichtaktivierte Module" weiter unten. Dann ist der Slot Forum frei. Damit gibt es kein Forum für alle Veranstaltungen der Seminarklasse. Der Dozent könnte das Forum damit auch nicht mehr aktivieren. Wenn Sie jetzt ein Plugin nehmen und als Inhaltselement in den Slot "Forum" fallen lassen, würde es wieder ein Forum für die Seminarklasse geben. Wenn der Dozent auf der Inhaltsseite das Forum deaktiviert oder aktiviert, wird davon jetzt immer das Plugin betroffen. Es gibt für den Dozenten jetzt keine Möglichkeit mehr, das Kern-Forum zurück zu bekommen und wieder zu aktivieren.

Die Modulslots betreffen also den kompletten Umgang und die Wahrnehmung der Nutzer einer Veranstaltung. Sie könnten einstellen, dass ein CMS-Plugin anstelle des normalen Wikis verwendet wird, dass Till Glögglers ForumPP-Plugin anstelle des normalen Forums benutzt wird und die Teilnehmerseite komplett ausgeblendet wird.

Ebenso können Sie Plugins auch aktivieren, ohne sie in einem Modulslot zuzuweisen. Es gibt dazu den Container "Aktivierte Plugins". Schieben Sie ein Plugin dort hinein, so wird das Plugin in neuen Veranstaltungen und solchen, die das Plugin noch nie aktiviert hatten, plötzlich aktiviert sein. Alle Plugin, die noch im Container "Nicht aktivierte Plugins" verbleiben, sind wie gehabt, nicht default-mäßig aktiviert, können aber vom Dozenten aktiviert werden. Ebenso können die von Ihnen aktivierten Plugins vom Dozenten auch wieder deaktiviert werden.

Jeder Inhaltselement, das Sie sehen, hat noch eine kleine Auswahlbox, die meistens "änderbar" stehen hat. Dieses "änderbar" bezieht sich auf die Möglichkeiten des Dozenten oder Admins. Wählen Sie stattdessen "nicht änderbar" aus, so hat der Dozent oder Admin keine Kontrolle mehr über die De/Aktivierung des Inhaltsmoduls und Ihre Eingabe ist komplett dominant. So ist das zum Beispiel für die Übersichtsseite. Bei der steht von Anfang an "nicht änderbar" mit einem kleinen rot Sicherheitsschloss daneben. Würden Sie dies umändern in "änderbar", so würde der Dozent plötzlich auf der Plus-Seite auswählen können, ob die Übersichtsseite der Veranstaltung aktiviert sein soll oder nicht. Sie geben dem Dozenten damit die Möglichgkeit, selbst darüber zu entscheiden. Da Sie aber vermutlich wollen, dass jede Veranstaltung dieser Seminarklasse eine Übersichtsseite hat, sollte der Dozent das vielleicht gar nicht einstellen dürfen. Also wieder das rote Schloss!

Ebenso können Sie für Plugins sagen, ob sie "nicht änderbar" sind. Ein Plugin im Container "Aktivierte Plugin", das zugleich "nicht änderbar" ist, kann vom Dozenten gar nicht mehr deaktiviert werden. Das würde sich beispielsweise für Evaluationen anbieten, die man nicht abstellen können soll. Ein Plugin, das im Container "Nicht aktivierte Plugins" steckt und zugleich "nicht änderbar" ist, kann hingegen niemals vom Dozenten aktiviert werden. Und wenn er es irgendwann mal zuvor aktiviert haben sollte, so ist diese Angabe Null und Nichtig und das Plugin wird trotzdem nicht angezeigt. So kann man Studentischen Arbeitsgruppen bestimmte Plugins wie eben Evaluationen von Lehrveranstaltungen zum Beispiel ganz verbieten.

Kern-Module wie das Kern-Forum, der Kern-Dateibereich und so weiter, die keinem Modulslot zugewiesen sind, sind immer deaktiviert. Das liegt einfach daran, dass diese Kernmodule nicht über die Datenbanktabelle "plugins_activated" aktiviert werden können. Das ist also eine technische Einschränkung. Denken Sie sich also das Auswahlfeld darunter wie ein dauerhaftes "nicht änderbar" mit dickem roten Schloss. Das wird Ihnen nicht angezeigt, weil Sie ja auch nichts daran ändern können. Was man nicht weiß, macht einen nicht heiß.

Eine Besonderheit gibt es noch bei der Verwaltungsseite. Ist der Slot "Verwaltung" leer, so kann ein Dozent die eigene Veranstaltung nicht mehr administrieren. Admins ebensowenig und sie finden die Veranstaltung nicht einmal mehr in ihrer Adminsuche. Studentische Arbeitsgruppen haben eine andere Verwaltungsseite (die theoretisch auch ausgetauscht werden kann). Sie bleiben damit bearbeitbar. Es kommt also nicht darauf an, welches Modul im Slot Verwaltung steckt, sondern nur ob eines drin ist oder nicht. Genau genommen ist diese Besonderheit aber auch logisch und sollte sich von selbst erschließen.