diff --git a/server.py b/server.py index 4c2b18c5affe183c11f1008caeb65e83ddfbda4d..6cde811ad414da123ebdc287e346521187c1b019 100755 --- a/server.py +++ b/server.py @@ -26,7 +26,7 @@ from shared import ( date_filter_short, time_filter, time_filter_short, user_manager, security_manager, current_user, check_login, login_required, class_filter, needs_date_test, todostate_name_filter, - code_filter, indent_tab_filter) + code_filter, code_key_filter, indent_tab_filter) from utils import ( get_first_unused_int, get_etherpad_text, split_terms, optional_int_arg, fancy_join, footnote_hash, get_git_revision, get_max_page_length_exp, @@ -110,6 +110,7 @@ app.jinja_env.filters["datify_long"] = date_filter_long app.jinja_env.filters["class"] = class_filter app.jinja_env.filters["todo_get_name"] = todostate_name_filter app.jinja_env.filters["code"] = code_filter +app.jinja_env.filters["code_key"] = code_key_filter app.jinja_env.filters["indent_tab"] = indent_tab_filter app.jinja_env.filters["fancy_join"] = fancy_join app.jinja_env.filters["footnote_hash"] = footnote_hash @@ -280,17 +281,115 @@ def index(): protocol=protocol, todos=todos, show_private=show_private, has_public_view_right=has_public_view_right) - @app.route("/documentation") @back.anchor @login_required def documentation(): - todostates = list(TodoState) - name_to_state = TodoState.get_name_to_state() return render_template( - "documentation.html", todostates=todostates, - name_to_state=name_to_state) + "documentation.html") + +@app.route("/documentation/sessionmanagement") +@back.anchor +@login_required +def sessionmanagement_documentation(): + return render_template( + "documentation-sessionmanagement.html") + +@app.route("/documentation/sessionmanagement/plan") +@back.anchor +@login_required +def plan_sessionmanagement_documentation(): + return render_template( + "documentation-sessionmanagement-plan.html") + +@app.route("/documentation/sessionmanagement/write") +@back.anchor +@login_required +def write_sessionmanagement_documentation(): + return render_template( + "documentation-sessionmanagement-write.html") + +@app.route("/documentation/sessionmanagement/tracking") +@back.anchor +@login_required +def tracking_sessionmanagement_documentation(): + return render_template( + "documentation-sessionmanagement-tracking.html") + +@app.route("/documentation/syntax") +@back.anchor +@login_required +def syntax_documentation(): + return render_template( + "documentation-syntax.html") + +@app.route("/documentation/syntax/meta") +@back.anchor +@login_required +def meta_syntax_documentation(): + return render_template( + "documentation-syntax-meta.html") + +@app.route("/documentation/syntax/top") +@back.anchor +@login_required +def top_syntax_documentation(): + return render_template( + "documentation-syntax-top.html") + +@app.route("/documentation/syntax/lists") +@back.anchor +@login_required +def lists_syntax_documentation(): + return render_template("documentation-syntax-lists.html") + +@app.route("/documentation/syntax/internal") +@back.anchor +@login_required +def internal_syntax_documentation(): + return render_template( + "documentation-syntax-internal.html") + +@app.route("/documentation/syntax/tags") +@back.anchor +@login_required +def tags_syntax_documentation(): + states = {state:[] for state in list(TodoState)} + name_to_state = TodoState.get_name_to_state() + for state_name in name_to_state: + states[name_to_state[state_name]].append(state_name) + return render_template( + "documentation-syntax-tags.html", states=states) + +@app.route("/documentation/configuration") +@back.anchor +@login_required +def configuration_documentation(): + return render_template( + "documentation-configuration.html") + +@app.route("/documentation/configuration/types") +@back.anchor +@login_required +def types_configuration_documentation(): + return render_template( + "documentation-configuration-types.html") +@app.route("/documentation/configuration/todomails") +@back.anchor +@login_required +def todomails_configuration_documentation(): + return render_template( + "documentation-configuration-todomails.html") + +@app.route("/documentation/configuration/settings") +@back.anchor +@login_required +def settings_configuration_documentation(): + user = current_user() + return render_template( + "documentation-configuration-settings.html", + system_administrator=(user is not None and config.ADMIN_GROUP in user.groups)) @app.route("/types/list") @back.anchor diff --git a/shared.py b/shared.py index 624570594275471d0f91215dde1c110869f1e80b..98954b70fd38e4bb97f747be6ea5b0da7a6abcf6 100644 --- a/shared.py +++ b/shared.py @@ -128,6 +128,8 @@ def class_filter(obj): def code_filter(text): return "{}".format(text) +def code_key_filter(text): + return '{}'.format(text) from common.auth import UserManager, SecurityManager, User max_duration = getattr(config, "AUTH_MAX_DURATION") diff --git a/static/css/pygments-manni.css b/static/css/pygments-manni.css new file mode 100644 index 0000000000000000000000000000000000000000..0fea96c6c3d9391701db41bcb5181761731531e8 --- /dev/null +++ b/static/css/pygments-manni.css @@ -0,0 +1,69 @@ +.highlight .hll { background-color: #ffffcc } +.highlight { background: #f0f3f3; } +.highlight .c { color: #0099FF; font-style: italic } /* Comment */ +.highlight .err { color: #AA0000; background-color: #FFAAAA } /* Error */ +.highlight .k { color: #006699; font-weight: bold } /* Keyword */ +.highlight .o { color: #555555 } /* Operator */ +.highlight .ch { color: #0099FF; font-style: italic } /* Comment.Hashbang */ +.highlight .cm { color: #0099FF; font-style: italic } /* Comment.Multiline */ +.highlight .cp { color: #009999 } /* Comment.Preproc */ +.highlight .cpf { color: #0099FF; font-style: italic } /* Comment.PreprocFile */ +.highlight .c1 { color: #0099FF; font-style: italic } /* Comment.Single */ +.highlight .cs { color: #0099FF; font-weight: bold; font-style: italic } /* Comment.Special */ +.highlight .gd { background-color: #FFCCCC; border: 1px solid #CC0000 } /* Generic.Deleted */ +.highlight .ge { font-style: italic } /* Generic.Emph */ +.highlight .gr { color: #FF0000 } /* Generic.Error */ +.highlight .gh { color: #003300; font-weight: bold } /* Generic.Heading */ +.highlight .gi { background-color: #CCFFCC; border: 1px solid #00CC00 } /* Generic.Inserted */ +.highlight .go { color: #AAAAAA } /* Generic.Output */ +.highlight .gp { color: #000099; font-weight: bold } /* Generic.Prompt */ +.highlight .gs { font-weight: bold } /* Generic.Strong */ +.highlight .gu { color: #003300; font-weight: bold } /* Generic.Subheading */ +.highlight .gt { color: #99CC66 } /* Generic.Traceback */ +.highlight .kc { color: #006699; font-weight: bold } /* Keyword.Constant */ +.highlight .kd { color: #006699; font-weight: bold } /* Keyword.Declaration */ +.highlight .kn { color: #006699; font-weight: bold } /* Keyword.Namespace */ +.highlight .kp { color: #006699 } /* Keyword.Pseudo */ +.highlight .kr { color: #006699; font-weight: bold } /* Keyword.Reserved */ +.highlight .kt { color: #007788; font-weight: bold } /* Keyword.Type */ +.highlight .m { color: #FF6600 } /* Literal.Number */ +.highlight .s { color: #CC3300 } /* Literal.String */ +.highlight .na { color: #330099 } /* Name.Attribute */ +.highlight .nb { color: #336666 } /* Name.Builtin */ +.highlight .nc { color: #00AA88; font-weight: bold } /* Name.Class */ +.highlight .no { color: #336600 } /* Name.Constant */ +.highlight .nd { color: #9999FF } /* Name.Decorator */ +.highlight .ni { color: #999999; font-weight: bold } /* Name.Entity */ +.highlight .ne { color: #CC0000; font-weight: bold } /* Name.Exception */ +.highlight .nf { color: #CC00FF } /* Name.Function */ +.highlight .nl { color: #9999FF } /* Name.Label */ +.highlight .nn { color: #00CCFF; font-weight: bold } /* Name.Namespace */ +.highlight .nt { color: #330099; font-weight: bold } /* Name.Tag */ +.highlight .nv { color: #003333 } /* Name.Variable */ +.highlight .ow { color: #000000; font-weight: bold } /* Operator.Word */ +.highlight .w { color: #bbbbbb } /* Text.Whitespace */ +.highlight .mb { color: #FF6600 } /* Literal.Number.Bin */ +.highlight .mf { color: #FF6600 } /* Literal.Number.Float */ +.highlight .mh { color: #FF6600 } /* Literal.Number.Hex */ +.highlight .mi { color: #FF6600 } /* Literal.Number.Integer */ +.highlight .mo { color: #FF6600 } /* Literal.Number.Oct */ +.highlight .sa { color: #CC3300 } /* Literal.String.Affix */ +.highlight .sb { color: #CC3300 } /* Literal.String.Backtick */ +.highlight .sc { color: #CC3300 } /* Literal.String.Char */ +.highlight .dl { color: #CC3300 } /* Literal.String.Delimiter */ +.highlight .sd { color: #CC3300; font-style: italic } /* Literal.String.Doc */ +.highlight .s2 { color: #CC3300 } /* Literal.String.Double */ +.highlight .se { color: #CC3300; font-weight: bold } /* Literal.String.Escape */ +.highlight .sh { color: #CC3300 } /* Literal.String.Heredoc */ +.highlight .si { color: #AA0000 } /* Literal.String.Interpol */ +.highlight .sx { color: #CC3300 } /* Literal.String.Other */ +.highlight .sr { color: #33AAAA } /* Literal.String.Regex */ +.highlight .s1 { color: #CC3300 } /* Literal.String.Single */ +.highlight .ss { color: #FFCC33 } /* Literal.String.Symbol */ +.highlight .bp { color: #336666 } /* Name.Builtin.Pseudo */ +.highlight .fm { color: #CC00FF } /* Name.Function.Magic */ +.highlight .vc { color: #003333 } /* Name.Variable.Class */ +.highlight .vg { color: #003333 } /* Name.Variable.Global */ +.highlight .vi { color: #003333 } /* Name.Variable.Instance */ +.highlight .vm { color: #003333 } /* Name.Variable.Magic */ +.highlight .il { color: #FF6600 } /* Literal.Number.Integer.Long */ diff --git a/templates/documentation-base.html b/templates/documentation-base.html new file mode 100644 index 0000000000000000000000000000000000000000..e2b61ffd133828c29ef6077d50e43ffb9164ac6e --- /dev/null +++ b/templates/documentation-base.html @@ -0,0 +1,75 @@ +{% extends "layout.html" %} +{% block additional_js %} + +{% endblock %} +{% set navigation_bar = [ + ('sessionmanagement_documentation', '/documentation/sessionmanagement', 'Sitzungsverwaltung', [ + ('plan_sessionmanagement_documentation', '/documentation/sessionmanagement/plan', 'Planung'), + ('write_sessionmanagement_documentation', '/documentation/sessionmanagement/write', 'Protokollieren'), + ('tracking_sessionmanagement_documentation', '/documentation/sessionmanagement/tracking', 'Nachverfolgung') + ]), + ('syntax_documentation', '/documentation/syntax', 'Syntax', [ + ('meta_syntax_documentation', '/documentation/syntax/meta', 'Metadaten'), + ('top_syntax_documentation', '/documentation/syntax/top', 'Tagesordnungspunkte'), + ('lists_syntax_documentation', '/documentation/syntax/lists', 'Listen'), + ('internal_syntax_documentation', '/documentation/syntax/internal', 'Interne Abschnitte'), + ('tags_syntax_documentation', '/documentation/syntax/tags', 'Tags') + ]), + ('configuration_documentation', '/documentation/configuration', 'Einrichtung', [ + ('types_configuration_documentation', '/documentation/configuration/types', 'Typen'), + ('todomails_configuration_documentation', '/documentation/configuration/todomails', 'Todo Mails'), + ('settings_configuration_documentation', '/documentation/configuration/settings', 'Systemeinstellungen') + ]) +] -%} +{% set active_page = active_page|default('documentation') -%} + +{% block content %} +
+
+ +
+
+ {% block documentation_content %} + Diese Seite ist leer. + {% endblock %} +
+
+{% endblock %} diff --git a/templates/documentation-configuration-settings.html b/templates/documentation-configuration-settings.html new file mode 100644 index 0000000000000000000000000000000000000000..ee7f5e4467e93fb9ddfa829f70c8ee8ab086d3ed --- /dev/null +++ b/templates/documentation-configuration-settings.html @@ -0,0 +1,67 @@ +{% extends "documentation-base.html" %} +{% set active_page = "settings_configuration_documentation" %} +{% block title %}Einrichtung: Systemeinstellungen{% endblock %} + +{% block documentation_content %} +

Einrichtung: Systemeinstellungen

+

+ Einige Features des Protokollsystems müssen bei der Installation und Einrichtung durch die Admins aktiviert werden. Dies ist eine Übersicht über die mit diesen Systemeinstellungen verbundenen Features. Sollten einige der angegeben Funktionalitäten aktiviert werden, so wende dich an die Admins. Bedenke vor deiner Anfrage, dass einige Features eventuell aus wichtigen Gründen bisher noch nicht aktiviert wurden. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureAktiviertKurzbeschreibung
E-MailversandDas System kann selbstständig E-Mails versenden, um über anstehende Sitzungen, neue Protokolle oder Todos zu informieren.
DruckeranbindungDas System kann Druckaufträge starten, um Beschlüsse oder Protokolle direkt über das Webinterface zu drucken.
EtherpadanbindungDas System kann mit einem Etherpad interagieren, um das Schreiben von Protokollen dort zu ermöglichen.
WikianbindungDas System kann veröffentlichte Protokolle in ein Wiki übertragen.
KalenderanbindungDas System kann eingetragene Sitzungstermine in einen Kalender übertragen.
Nutzung interner AbschnitteDas System bietet die Möglichkeit bestimmte Abschnitte als nicht-öffentlich/intern zu kennzeichnen.
Angepasste StandardvorlageDas System nutzt die Standardprotokollvorlage in einer angepassten Form - ggf. mit Logo, Kopf-/Fußzeile oder anderen Seitenformaten bzw. -abständen
Individuelle ProtokollvorlagenDas System stellt zusätzlich zur Standardvorlage individuelle Protokollvorlagen zur Verfügung, die zuvor erstellt und durch die Administratoren eingespielt wurden.
+ {% if system_administrator and git_revision %} +

Hinweise für Administratoren

+

+ Eine Beschreibung der Einrichtung des einzelnen Features kann der Projektseite der Software „Protokollsystem 3“ entnommen werden. Bitte lies dir die README.md aufmerksam durch und entnimm bei Bedarf Konfigurationsbeispiele aus config.py.example. Bei schwerwiegenden Problemen kontaktiere die Entwickler. +

+ {% endif %} +{% endblock %} diff --git a/templates/documentation-configuration-todomails.html b/templates/documentation-configuration-todomails.html new file mode 100644 index 0000000000000000000000000000000000000000..8f2660153302caff2c43341be111d0197f9f3aa6 --- /dev/null +++ b/templates/documentation-configuration-todomails.html @@ -0,0 +1,73 @@ +{% extends "documentation-base.html" %} +{% set active_page = "todomails_configuration_documentation" %} +{% block title %}Einrichtung: Todo Mails{% endblock %} + +{% block documentation_content %} +

Einrichtung: Todo Mails

+ {% if config.MAIL_ACTIVE %} +

+ Werden im Protokollsystem im Rahmen einer Sitzung Aufgaben verwaltet, so kann eingestellt werden, dass die mit der Aufgabe betrauten Personen eine Benachrichtigung erhalten können. Damit diese Personen eine Benachrichtigung erhalten kann, sollten zu jedem genutzten Personenkürzel eine E-Mailadresse hinterlegt werden. Diese Konfiguration erfolgt zentral auf der Übersicht der Todo-Mail-Zuordnungen. +

+
+
+
Beispiel - Übersicht Todo-Mail-Zuordnungen
+
+
+

Todo-Mail-Zuordnungen Neu

+ + + + + + + + + + + + + + + + + + + + +
NameMail
mmustermannmmustermann@domain.exampleÄndern, Löschen
kmusterfraukmusterfrau@domain.exampleÄndern, Löschen
+
+
+

+ Auf der Übersicht kann über die Schaltfläche „neu“ eine entsprechende Todo-Mail-Zuordnungen angelegt werden. Bereits bestehende Belegungen können jederzeit angepasst oder gelöscht werden. Beim Anlegen bzw. der Bearbeitung müssen stets das genutzten Personenkürzel (Name) sowie die korresspondierende E-Mailadresse angegeben werden. +

+
+
+
Beispiel - Todo-Mail anlegen bzw. bearbeiten
+
+
+
+
+ + +
+
+ + +
+ +
+
+
+ {% else %} +
+
+
Nutzung nicht vorgesehen
+
+
+

+ Das Versenden von E-Mails zu offenen Aufgaben ist hier bisher noch nicht vorgesehen. Um den automatischen E-Mailversand nutzen zu können, wende dich bitte an die Admins und lasse die Konfiguration durch sie entsprechend anpassen. +

+
+
+ {% endif %} +{% endblock %} diff --git a/templates/documentation-configuration-types.html b/templates/documentation-configuration-types.html new file mode 100644 index 0000000000000000000000000000000000000000..693d3dadf4298075da3bfacf7fb980864fabc453 --- /dev/null +++ b/templates/documentation-configuration-types.html @@ -0,0 +1,532 @@ +{% extends "documentation-base.html" %} +{% set active_page = "types_configuration_documentation" %} +{% block title %}Einrichtung: Typen{% endblock %} + +{% block documentation_content %} +

Einrichtung: Typen

+

+ Damit Protokolle im Protokollsystem überhaupt geschrieben und Sitzungen verwaltet werden können, ist es unerlässlich entsprechende Protokolltypen anzulegen. Auf der Protokolltypen-Übersichtsseite werden die Typen aufgelistet, wobei nur die Typen angezeigt werden, deren Protokolle man sehen darf (weiteres hierzu unter Rechtekonfiguration). +

+
+
+
Beispiel - Übersicht Protokolltypen
+
+
+

Protokolltypen Neu

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ +

Protokolltyp

+

+ Auf der Übersichtsseite kann über die Schaltfläche „neu“ ein entsprechender Protokolltyp angelegt werden. Bereits bestehende Protokolltypen können abhängig von der Berechtigung angepasst werden. Der Protokolltyp beinhaltet Einstellung die vom Protokollsystem stets für diesen Typ verwendet werden. Dazu gehören der Anzeigename und die Abkürzung des Sitzungstyps, die sitzungsabhaltende Organisation, der Standardbeginn der Sitzung sowie die Vorlageneinstellung. +

+

+ Zu beachten ist, dass der Anzeigename des Sitzungstyps nur im Protokolltyp angepasst werden kann und im Protokoll ein Teil der Überschrift ist. + {% if config.WIKI_ACTIVE %} + Je Typ kann angegeben werdem, ob das Protokoll im Status veröffentlicht in das Wiki exportiert werden soll, wobei eien Kategorie anzugeben ist. + {% endif %} + {% if config.PRINTING_ACTIVE %} + Auch kann der Standarddrucker festgelegt werden, der für den Protokolltyp genutzt werden soll. + {% endif %} + {% if config.CALENDAR_ACTIVE %} + Des weiteren kann bei Bedarf der externe Kalender ausgewählt werden, in den die Sitzungstermine des Protokolltyp geschrieben werden sollen. + {% endif %} + {% if config.LATEX_LOCAL_TEMPLATES and config.LATEX_TEMPLATES %} + Es kann pro Protokolltyp eine der konfigurierten Vorlagen ausgewählt werden, die bei der Erstellung der PDF genutzt wird. + {% endif %} + Weitere Einstellungen, auf die im folgenden genauer eingegangen wird, sind: +

+ +
+
+
Beispiel - Protokolltyp anlegen
+
+
+
+
+ + +
+
+ + +
+
+ + +
+
+ + +
+
+ +
+ +
+ + +
+
+ + +
+
+ + +
+
+ + +
+
+ +
+ +
+ + +
+
+ + +
+
+ + +
+
+ +
+ +
+ +
+ +
+ + +
+
+ + +
+
+ +
+ +
+ + +
+
+ + +
+ +
+
+
+ +

Rechtekonfiguration

+
+
+

+ Um zu ermöglichen, dass nur bestimmte Personengruppen auf Protokolle zugreifen können hat das Protokollsystem ein Konzept von Rechteverwaltung, dass auf den Benutzergruppen des konfigurierten Authentifizierungsdienstes (LDAP, Active-Directory oder sonstiges Auth-Backend) basiert. Die Einstellung der Rechte erfolgt pro Protokolltyp, in dem den Gruppen des Protokolltyps eine passende Benutzergruppe zugeordnet wird. +

+

+ Jeder Protokolltyp verfügt über eine öffentliche Gruppe, eine interne Gruppe, eine Bearbeitungsgruppe, eine Verwaltungsgruppe und eine Einstellung, ob der Typ öffentlich ist. In der folgenden Tabelle werden die vorhandenen Rechte dargestellt und in Verbindung zu den Gruppen des Protokolltyps gesetzt. +

+
+
+
+
+
Zu beachten
+
+
+ Ein Recht einer Gruppe kann nur ausgeübt werden, wenn eine Benutzergruppen zugeordnet wurde. +
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
RechtBerechtigte Gruppen
darf öffentliche Version einsehenjeder, wenn Protokolltyp als öffentlich gekennzeichnet und Protokoll veröffentlicht; öffentliche Gruppe; interne Gruppe; Benutzergruppe „{{config.ADMIN_GROUP}}“
darf interne Version einseheninterne Gruppe; Benutzergruppe „{{config.ADMIN_GROUP}}“
darf ändernBearbeitungsgruppe; Benutzergruppe „{{config.ADMIN_GROUP}}“
darf Protokolltyp bearbeitenVerwaltungsgruppe; Benutzergruppe „{{config.ADMIN_GROUP}}“
+

+ Vom Protokoll wird eine interne und eine öffentliche Version generiert, falls es Inhalte gibt, die nur intern sind. Todos sind generell intern und Beschlüsse sind generell öffentlich, d.h. einsehbar, wenn man das Recht „darf öffentliche Version einsehen“ hat. Daher dürfen Beschlüsse nicht in einem internen Teil des Protokolls sein. +

+ +

Zugriffskonfiguration

+

+ Mit der Einstellung der Nutzerrechte kann der Zugriff auf Protokolle nur nach der erfolgreichen Authentifikation gesteuert werden. Soll der Zugriff auf öffentliche Protokolle weiter reduziert werden, so kann auf das Computernetzwerkes, dem der Zugriff gewährt werden soll, eingeschrängt werden. Dies erfolgt durch die Angabe einzelner oder mehrerer Netzwerkbereiche (vergl. Wikipedia). Bei der Angabe mehrerer Bereiche werden diese durch ein Komma voneinander getrennt. +

+

+ Soll nur die Tagesordnung öffentlich gemacht werden, so muss die Option „Netzwerke einschränken“ ohne die Angabe eines Netzwerkbereiches aktiviert und der Protokolltyp als öffentlich gekennzeichnet werden. +

+ + {% if config.MAIL_ACTIVE %} +

E-Maileinstellungen

+

+ Die Möglichkeit E-Mails direkt aus dem Protokollsystem zu versenden, kann sich auch bei der Einrichtung von Protokolltypen zunutzegemacht werden. Hierfür können zwei E-Mailadressen hinterlegt werden: Ein interner und ein öffentlicher Verteiler. Diese werden vom System beim Versenden des entsprechenden Protokolls verwendet. Beide Verteiler können auch für automatisierte Einladungsmails herangezogen werden. Diese Mails müssen für jeden Protokolltyp individuell erstellt werden und können in den Einstellung des Typs eingesehen werden. +

+
+
+
Beispiel - Übersicht Einladungsmails
+
+
+

Einladungsmails Neu

+ + + + + + + + + + + + + + + + + +
ZeitEinladenZusätzlicher Mailinhalt
1 TageInternEs ist mal wieder soweit und unsere Sitzung soll mit der angegeben TO statt finden.Ändern, Löschen
+
+
+

+ Bei der Erstellung kann festgelegt werden wie viele Tage vor der Sitzung eingeladen werden soll. Ebenfalls wird angegeben, an welche Verteiler diese automatisierte Einladung geschickt wird. Zusätzlich zur Tagesordnung und dem Datum der Sitzung kann ein individueller Mailinhalt hinterlegt werden, der zusätzlich mit versendet wird. +

+
+
+
Beispiel - Einladungsmail anlegen
+
+
+
+
+ + +
+
+ +
+ +
+ +
+ +
+ + +
+ +
+
+
+ {% endif %} + +

Standard-TOPs

+

+ Häufig werden für eine Sitzung immer wieder die gleichen Tagesordnungspunkte in einer immer gleichen Reihenfolge benötigt, teilweise ergibt sich dies aus den Ordnungen nach denen eine Sitzung stattfindet. Diese Standard-TOPs können pro Protokolltyp festgelegt und in den Einstellung des Typs eingesehen werden. Beim Anlegen einer Sitzung werden die Standard-TOPs des Protokolltyps eingefügt. +

+
+
+
Beispiel - Übersicht Standard-TOPs
+
+
+

Standard-TOPs Neu

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TOPSortierung
Begrüßung, Beschluss der TO und Protokolle-100Runter, Hoch, Ändern, Löschen
Bericht-90Runter, Hoch, Ändern, Löschen
Todos-80Runter, Hoch, Ändern, Löschen
Verschiedenes100Runter, Hoch, Ändern, Löschen
+
+
+

+ Werden Standard-TOPs angelegt so muss der Name des Tagesordnungspunktes stets angegeben werden. Die Reihung der TOPs kann über die Priorität bzw. Sortierung gesteuert werden. Dabei gilt: Standard-TOPs mit negativer Priorität werden vor und die mit positiver Priorität nach den Tagesordnungspunkten eines Protokolls eingefügt. Einem Standard-TOP kann zusätzlich ein feststehender vorprotokollierter Inhalt mitgegeben werden. +

+
+
+
Beispiel - Standard-TOP anlegen
+
+
+
+
+ + +
+
+ + +
+
+ + +
+ +
+
+
+ +

Metadatenfelder

+

+ In einem Protokoll repräsentieren die Metadaten allgemeine Informationen rund um eine Sitzung. Die zuerfassenden Metadaten können für jeden Protokolltyp unterschiedlich sein und werden dementsprechend pro Typ verwaltet. Nur die im Protokolltyp angegeben Metadaten können überhaupt - müssen dann aber auch - beim Protokollieren erfasst werden. Ausgenommen von der Verwaltbarkeit sind die im Protokollsystem als Standard festgelegten Felder: Datum, Beginn und Ende. +

+
+
+
Beispiel - Übersicht Metadatenfelder
+
+
+

Metadatenfelder Neu

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameKeyStandardwertInternVorher
OrtOrtFachschaftsraumNeinNeinÄndern, Löschen
AnwesendAnwesendNeinNeinÄndern, Löschen
ProtokollProtokollNeinNeinÄndern, Löschen
+
+
+

+ Die Konfiguration eines Metadatenfeldes beinhaltet immer den Anzeigenamen (Name) und den beim Protokollieren zu verwendenden Namen des Feldes (Key). Des weiteren ist es möglich einen Standardwert für das Metadatenfelder zu hinterlegen, welcher beim Erstellen einer neuen Sitzung in das Feld geschrieben wird, so fern es als Planungsrelevant (vorher) markiert wurde. Zudem ist es möglich Metadaten nur in der internen Version eines Protokolls anzuzeigen, wenn das entsprechende Feld als intern festgelegt wurde. +

+
+
+
Beispiel - Metadatenfeld anlegen
+
+
+
+
+ + +
+
+ + +
+
+ + +
+
+ +
+ +
+ +
+ + +
+
+
+ +

Beschlusskategorien

+

+ Um Beschlüsse zu einzelnen Themen bzw. Kategorien zusammenfassen zu können, werden je Protokolltyp die benötigten Beschlusskategorien angelegt und verwaltet. Die verfügbaren Kategorien lassen sich im Beschluss-Tag verwenden. Fehlende Kategorien lassen sich jeder Zeit durch Angabe des Kategorienames ergänzen. Bisher nicht verwendete Kategorien können gefahrlos gelöscht werden. +

+
+
+
Beispiel - Beschlusskategorien verwalten
+
+ +
+{% endblock %} diff --git a/templates/documentation-configuration.html b/templates/documentation-configuration.html new file mode 100644 index 0000000000000000000000000000000000000000..4de6fb2aa49189515b4fb32f669f46f9e82b34c9 --- /dev/null +++ b/templates/documentation-configuration.html @@ -0,0 +1,17 @@ +{% extends "documentation-base.html" %} +{% set active_page = "configuration_documentation" %} +{% block title %}Einrichtung{% endblock %} + +{% block documentation_content %} +

Einrichtung

+

+ Eine wichtige Eigenschaft des Protokollsystems ist die Konfigurierbarkeit. Das System lässt sich individuell auf die Bedürfnisse der eigenen Organisationseinheit anpassen. Einige Einstellungen können direkt über die Weboberfläche vorgenommen werden und stehen allen Benutzern zur Verfügung. Dazu gehören: +

+ +

+ Andere Einstellungen werden direkt bei der Installation und Einrichtung des Protokollsystems durch die Admins vorgenommen. Zu diesen Systemeinstellungen zählen unter anderem Features wie das automatische Versenden von E-Mails oder die Nutzung eines Etherpads zum Schreiben von Protokollen. +

+{% endblock %} diff --git a/templates/documentation-sessionmanagement-plan.html b/templates/documentation-sessionmanagement-plan.html new file mode 100644 index 0000000000000000000000000000000000000000..eabc083a242ab91e894b1e6959d8c1dfe5562528 --- /dev/null +++ b/templates/documentation-sessionmanagement-plan.html @@ -0,0 +1,324 @@ +{% extends "documentation-base.html" %} +{% set active_page = "plan_sessionmanagement_documentation" %} +{% block title %}Sitzungsverwaltung: Planung{% endblock %} + +{% block documentation_content %} +

Sitzungsverwaltung: Planung

+

+ Im Vorfeld einer Sitzung sollten verschiedene Tätigkeiten vorgenommen werden. Hierbei ist zu unterscheiden ob zu einem geplanten Sitzungstermin bereits ein Protokoll existiert oder nicht. Zu bereits existierenden und noch nicht geschriebenen Protokollen kann die Tagesordnung verwaltet werden. +

+ +

Nicht existierendes Protokoll

+

+ Versichere dich zuerst auf der Protokollübersichtsseite, dass das Protokoll nicht bereits existiert. Sollte das Protokoll noch nicht existieren, so führe die folgenden Schritte aus um es anzulegen. +

+
    +
  1. Gehe auf Neues Protokoll.
    2. +
  2. Wähle bei „Typ“ den Typ der Sitzung aus.
    3. +
  3. Gib das Datum der Sitzung und ggf. einen Startzeitpunkt ein.
    4. +
  4. Klicke auf Anlegen.
    5. +
+
+
+
Beispiel - Neues Protokoll anlegen
+
+
+

Neue Sitzung

+
+
+ + +
+
+ + +
+
+ + +
+ +
+
+
+ +

Existierendes Protokoll finden

+

+ Ist das Protokoll bereits angelegt, so kann es auf zwei verschiedenen Wegen gefunden werden. Zum einen über die Übersicht der nächsten Sitzungen auf der Startseite und zum anderen auf der Protokollübersichtsseite. +
+ Um ein Protokoll auf der Protokollübersichtsseite zu finden: +

+
    +
  1. Gehe auf Protokolle,
    2. +
  2. Wähle die Sitzung aus - noch ausstehende Sitzungen sind ganz oben. +
+
+
+
Beispiel - Protokollübersicht
+
+
+
+
+ +
+
+ +
+
+ +
+ +
+

Protokolle Neu

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+
+
+
+
+
+ +
+
+
+ +
+
+
+ +
+
+
+ +
+
+
+ Geplant, + Fertig, + Veröffentlicht +
+
+
+ +

Existierendes Protokoll vorbereiten

+

+ Soll ein bereits existierendes Protokoll für die Sitzung vorbereitet oder angepasst werden, so ist das Protokoll entsprechend wie oben dargestellt aufzurufen. Auf der Seite der Sitzung werden neben verschiedenen sogenannten Metadaten, wie Datum und Uhrzeit der Sitzung, auch die Tagesordnung dargestellt. +
+ Haben sich in den für die Sitzung angegebenen Metadaten Fehler eingeschlichen oder soll die Sitzung beispielsweise verschoben werden, so können diese Protokolldaten wie folgt bearbeitet und aktualisiert werden. +

+
    +
  1. Klicke auf Editieren.
    2. +
  2. Passe die Daten auf der neu geladenen Seite entsprechend an.
    3. +
  3. Speichere die Ändernungen durch das Klicken auf Ändern.
    4. +
+
+
+
Beispiel - Protokolldaten aktualisieren
+
+ +
+

+ Für jede Sitzung kann auch die Tagesordnung individuell angepasst werden. Zwar gibt es einige Tagesordnungspunkte, die bereits durch den Sitzungstyp vorgegeben sind (sogenannte Standard-TOPs), weitere Punkte können aber jeder Zeit hinzugefügt werden. Des weiteren besteht für jeden TOP die Möglichkeit durch sogenanntes Vorprotokollieren bereits bekannte Informationen zum TOP vor der Sitzung hinzuzufügen, wie bswp. einen schriftlichen Bericht. +
+ Bitte beachte weiterhin die folgenden Punkte beim Umgang mit Tagesordnungspunkten:

+ +
+
+
Beispiel - Übersicht der Tagesordnung
+
+
+

Tagesordnung Top hinzufügen

+ +
+
+
+
+
Beispiel - Neuen TOP anlegen oder bestehenden TOP bearbeiten
+
+
+
+
+ + +
+
+ + +
+
+ + +
+ +
+
+
+

+ Im Einsatz des Protokollsystem hat sich bereits gezeigt, dass die folgenden Ratschläge dazubeitragen können, bereits aus der Tagesordnung zu erkennen, was behandelt werden soll. +

+ +{% endblock %} diff --git a/templates/documentation-sessionmanagement-tracking.html b/templates/documentation-sessionmanagement-tracking.html new file mode 100644 index 0000000000000000000000000000000000000000..f5533917871ed9751ef08fd03f9d7a2573e516c9 --- /dev/null +++ b/templates/documentation-sessionmanagement-tracking.html @@ -0,0 +1,242 @@ +{% extends "documentation-base.html" %} +{% set active_page = "tracking_sessionmanagement_documentation" %} +{% block title %}Sitzungsverwaltung: Nachverfolgung{% endblock %} + +{% block documentation_content %} +

Sitzungsverwaltung: Nachverfolgung

+

+ Nachdem eine Sitzung beendet und das Protokoll importiert wurde, können in einer Sitzung gefasste Beschlüsse und verteilte Aufgaben eingesehen sowie nachverfolgt werden. +

+ +

Beschlüsse

+

+ Alle in den Protollen festgehaltenen Beschlüsse werden in der Beschlussübersicht angezeigt. Neben dem Beschlusstext beinhaltet die Übersicht die zu den Beschlüssen gehörenden Protokoll sowie die Beschlusskategorie. In den einzelnen Protokollen werdend die Beschlüsse ebenfalls zusammengefasst dargestellt, um einen Überbrlick über alle Beschlüsse der betrefenden Sitzung zu erhalten. +

+ {% if config.PRINTING_ACTIVE %} +

+ Beschlüsse können direkt aus dem Protokollsystem an den im Protokolltyp hinterlegten Drucker durch klicken auf „Drucken“ zum Drucken gesendet werden, so dass gedruckte Beschlüsse beispielsweise mit Kassenanweisungen abgeheftet werden können. +

+ {% endif %} +
+
+
Beispiel - Beschlussübersicht
+
+
+
+
+ +
+
+ +
+
+ +
+ +
+

Beschlüsse Neu

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SitzungBeschlussKategorie
Sitzung-18-03-01Die Sitzung beschließt den Finanzplan der ESA (M/0/2).finanzwirksam{% if config.PRINTING_ACTIVE %}Drucken{% endif %}
Sitzung-18-03-01Die Sitzung beschließt die ESAG mit nach Kräften zu unterstützen (5/1/3).ESA{% if config.PRINTING_ACTIVE %}Drucken{% endif %}
Arbeitsgruppe-18-02-15Die Arbeitsgruppe wählt Katrin Musterfrau als Eventkoordination (M/0/0).{% if config.PRINTING_ACTIVE %}Drucken{% endif %}
+
+
+ +

Aufgaben (Todos)

+

+ Einzelne Aufgaben, die während oder außerhalb einer Sitzung vergeben werden, können mit dem Protokollsystem über mehrere Protokolle hinweg verwaltet werden. Offene Todos werden dabei automatisch in die Protokollvorlage eingefügt, falls diese einen Standard-TOP „Todos“ beinhaltet. Darüberhinaus können alle Todos auf der entsprechenden Übersichtsseite eingesehen werden. +

+
+
+
Beispiel - Todoübersicht
+
+
+
+
+ +
+
+ +
+
+ +
+ +
+

Todos Neu

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Aufgabe
Mit der Fakultät treffen
Organisiation des nächsten Events
+
+
+

+ Aufgaben können im Protokollsystem auch außerhalb eines Protokolls direkt auf der Übersichtsseite über die Schaltfläche „neu“ angelegt werden. Zu jeder Aufgabe sollte mindestens eine Person zugeordnet werden, die das Todo erledigt. Werden mehrere Personen angegeben, so sind diese durch Kommata oder Leerzeichen zu trennen. In aller Regel wird für jede Person ein internes Personenkürzel für die Zuweisung einer Aufgabe genutzt. Damit diese Personen eine Benachrichtigung über das neue Todo erhalten, sollten zu jedem internen Personenkürzel eine E-Mailadresse hinterlegt werden. +

+
+
+
Beispiel - Todo anlegen
+
+
+
+
+ + +
+
+ + +
+
+ + +
+
+ + +
+
+ + +
+ +
+
+
+

+ Neben der eigentlichen Aufgabe und den zugeordneten Personen haben Todos auch einen Zustand, in dem sie sich befinden. Die folgende Tabelle listet die möglichen Zustände und ihre Bedeutung auf. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZustandBedeutung
offenDas Todo muss noch erledigt werden
wartet auf RückmeldungJemand kümmert sich um das Todo, wartet allerdings gerade darauf, dass jemand anderes (intern oder extern) sich zurückmeldet.
in BearbeitungJemand kümmert sich gerade um das Todo.
abDas Todo wird erst ab dem Datum relevant.
vorDas Todo muss vor dem Datum erledigt werden.
verwaistDas Todo hat niemanden, der es erledigen wird.
erledigtDas Todo ist erledigt.
abgewiesenDas Todo ist nicht und wird nicht mehr erledigt.
obsoletDas Todo wurde nicht erledigt und nun ist es zu spät, das noch zu tun.
+{% endblock %} diff --git a/templates/documentation-sessionmanagement-write.html b/templates/documentation-sessionmanagement-write.html new file mode 100644 index 0000000000000000000000000000000000000000..f329d1cf6ece8503562a208e23d5854d2208863f --- /dev/null +++ b/templates/documentation-sessionmanagement-write.html @@ -0,0 +1,255 @@ +{% extends "documentation-base.html" %} +{% set active_page = "write_sessionmanagement_documentation" %} +{% block title %}Sitzungsverwaltung: Protokollieren{% endblock %} + +{% block documentation_content %} +

Sitzungsverwaltung: Protokollieren

+

+ Der wichtigeste Bestandteil des Protokollsystems ist sicherlich das Schreiben des Protokolls selbst. Ist eine Sitzung fertig vorbereitet und beginnt die Sitzung in wenigen Minuten so kann das benötigte Protokoll ausgewählt werden. Anschließend kann das Mitschreiben beginnen. +

+

+ Der folgende allgemeine Ablauf soll einen Überblick der Schritte geben, die beim Protokollieren im Protokollsystem vorgenommen werden. Dabei ist der Prozess in drei Phasen unterteilt: +

+ + +

Mit Beginn einer Sitzung

+

+ Kurz bevor die Sitzung los geht oder mit dem Beginn der Sitzung wird das Protokoll erzeugt und die offenen Metadaten ausgefüllt. Um dies zu erreichen werden die folgenden Schritte durchgeführt. +

+
    +
  1. Stelle sicher, dass alle mit dem Vorprotokollieren fertig sind.
    2. + {% if config.ETHERPAD_ACTIVE %} +
  2. Durch betätigen des Knopfes „Etherpad“ das Etherpad mit dem Protokoll öffnen. Bitte beachte: Nur beim ersten Betätigen werden die TOPs und die vorprotokollierten Inhalte ins Etherpad übertragen.
    3. + {% else %} +
  3. Durch betätigen des Knopfes „Vorlage“ eine Textdatei mit der Protokollvorlage herunterladen.
    4. + {% endif %} +
+
+
+
Beispiel - Protokoll{% if config.ETHERPAD_ACTIVE %} ins Etherpad übertragen{% else %}vorlage herunterladen{% endif %}
+
+
+
+ {% if config.ETHERPAD_ACTIVE %} + Aus Etherpad + {% endif %} + Editieren + {% if config.ETHERPAD_ACTIVE %} + Etherpad + {% endif %} + Vorlage + {% if config.MAIL_ACTIVE %} + Einladung versenden + {% endif %} + Typ +
+
+
+ +

Während einer Sitzung

+

+ Läuft eine Sitzung so gibt es neben der Syntax des Protokolls auch weitere Punkte zu beachten. +

+ +
+
+
Beispiel - Ausschnitt eines Protokolls
+
+
+ 
#Datum;14.03.2018
+#Beginn;17:00
+#Ende;
+...
+[todo;Diese Aufage ist noch offen;id 5;erledigt]
+...
+[beschluss;Die Sitzung genehmigt das Protokoll einstimmig]
+
+
+ +

Nach der Sitzung

+

+ Ist die Sitzung zu Ende so kann die Protokoll-PDF-Datei erzeugt werden. Nicht immer klappt dies Reibungslos und gelegentlich schleichen sich Rechtschreibfehler ein, weshalb die folgenden Schritte dazu dienen Fehler so weit wie möglich zu entfernen. +

+
    + {% if config.ETHERPAD_ACTIVE %} +
  1. Importiere das Protokoll am Ende der Sitzung mit „Aus Etherpad“.
    2. + {% else %} +
  2. Importiere das Protokoll am Ende der Sitzung über „Hochladen → Quellcode“.
    3. + {% endif %} +
  3. Falls Fehler beim Erstellen PDF-Date der auftreten, behebe diese und importiere das Protkoll erneut. Ein Auflistung wird dir nach dem Aktualisieren der Webseite oder auf der Fehlerübersichtsseite angezeigt.
    4. +
+
+
+
Beispiel - Protokoll importieren
+
+
+ {% if config.ETHERPAD_ACTIVE %} +
+ Aus Etherpad + Editieren + Etherpad + Vorlage + {% if config.MAIL_ACTIVE %} + Einladung versenden + {% endif %} + Typ +
+ {% else %} +
+
+ + +
+ +
+ {% endif %} +
+
+ +

+ Nach dem das Sitzungsprotokoll vorläufig fertiggestellt ist, kann in den Korrekturprozess eingestiegen werden. +

+
    + {% if config.MAIL_ACTIVE %} +
  1. Wenn keine Fehler mehr auftreten, verschicke das Protokoll mit „Intern versenden”.
    2. + {% else %} +
  2. Wenn keine Fehler mehr auftreten, gib den Sitzungsteilnehmern Bescheid, dass das Protkoll fertiggestellt ist. Das Protokoll kann mit „Download” heruntergeladen werden.
    3. + {% endif %} +
  3. Lasse das Protokoll korrekturlesen und korrigieren.
    4. + {% if config.ETHERPAD_ACTIVE %} +
  4. Importiere das Protokoll nach den Korrekturen erneut mit „Aus Etherpad“.
    5. + {% else %} +
  5. Importiere das Protokoll nach den Korrekturen erneut über „Hochladen → Quellcode“.
    6. + {% endif %} +
+
+
+
Beispiel - Protokoll korrekturlesen
+
+
+
+ {% if config.ETHERPAD_ACTIVE %} + Aus Etherpad + {% endif %} + Quelltext + Editieren + {% if config.ETHERPAD_ACTIVE %} + Etherpad + {% endif %} + {% if config.MAIL_ACTIVE %} + Intern versenden + {% endif %} + Veröffentlichen + Typ + Download +
+
+
+ +

+ Sind die Korrekturen abgeschlossen, so kann zur Veröffentlichung geschritten werden. +

+
    +
  1. Warte alle Korrekturen ab. Ggf. werden letzte Korrekturen mit einer etwaigen Genehmigung des Protokolls auf der nächsten Sitzung vorgenommen.
    2. +
  2. Veröffentliche das Protkoll mit „Veröffentlichen“.
    3. + {% if config.MAIL_ACTIVE %} +
  3. Versende das Protkoll ggf. über den öffentenlichen Verteiler mit „Öffentlich versenden“.
    4. + {% endif %} +
+
+
+
Beispiel - Protokoll veröffentlichen und versenden
+
+ +
+ + {% if config.ETHERPAD_ACTIVE %} +

Bekannte Problem bei der Etherpadnutzung

+
Leeres Etherpad
+

+ Wird mit „Etherpad“ ein Pad geöffnet und es ist leer bzw. beinhaltet nur den Standardtext, so sollte das Etherpad mit „Etherpad“ erneut geöffnet werden. Schlägt das ganze fehl, wende dich bitte an an die Admins. +

+
Etherpad zu früh geöffnet
+

+ Wurde das Pad zu früh erstellt und es wurden noch nicht alle TOPs bzw. alle vorprotokollierten Teil in das Pad übernommen und es zu aufwendig ist diese manuell einzufügen, so lösche den Inhalt des Pad und öffne das Pad erneut mit „Etherpad“. +

+
Höchst interne Protokolle
+

+ Falls das Protokoll Daten beinhaltet, die auf keinen Fall öffentlich sein sollten (z.B. personenbezogene Daten bei einem Sozialausschuss), kann anstelle des Editierens im Etherpad auch mit „Vorlage“ die leere Protokollvorlage heruntergeladen werden. Darin kann lokal mit einem beliebigen Texteditor die Sitzung protokolliert werden, um sie dann am Ende lokal zu speichern und mit „Quellcode hochladen“ hochzuladen. +

+
+
+
Beispiel - Höchst interne Protokolle
+
+ +
+ {% endif %} +{% endblock %} diff --git a/templates/documentation-sessionmanagement.html b/templates/documentation-sessionmanagement.html new file mode 100644 index 0000000000000000000000000000000000000000..350938876a344c1eb5980aed274e9ee9bd7ed9aa --- /dev/null +++ b/templates/documentation-sessionmanagement.html @@ -0,0 +1,32 @@ +{% extends "documentation-base.html" %} +{% set active_page = "sessionmanagement_documentation" %} +{% block title %}Sitzungsverwaltung{% endblock %} + +{% block documentation_content %} +

Sitzungsverwaltung

+

+ Ein wesentlicher Bestandteil des Protokollsystems ist das Sitzungsmanagement. Neben dem Planen und Anlegen verschiedener Sitzungstermine kann zu jeder Sitzung ein Protokoll verfasst und anschließend durch das System ausgegeben werden. Die Nachverfolgung von Ergebnissen ist im System in Form von Beschlüssen und Todos möglich. +

+

Verwaltung im Detail

+

+ Die einzelnen Funktionen des Sitzungsmanagements werden jeweils auf Unterseiten erläutert. Auch werden die Arbeitsabläufe, wie sie im System vorgesehen sind, vorgestellt. +

+ +

+ Sollten die genannten Arbeitsabläufe nicht nachvollziehbar oder fehlerhaft sein, dann kontaktiere bitte das Entwicklungsteam der Software. Als Tipp: Je genauer du ein Problem beschreiben kannst, desto einfacher machst du es den betroffenen Personen selbiges zu fixen und desto schneller hast du eine Lösung. +

+ +

Suche

+

+ Einige Elemente der Sitzungsverwaltung sind durchsuchbar - dazu zählen Protokolle, Todos und Beschlüsse. Auf jeder der Übersichtsseiten wird ein Suchfeld vorgehalten, das zur Eingabe genutzt werden kann. +

+

+ Im Suchfeld können mehrere durch Leerzeichen getrennte Suchbegriffe angegeben werden: Begriff1 Begriff2.
+ Angezeigt werden alle Ergebnisse, die jeden der Suchbegriffe (unabhängig von Groß- oder Kleinschreibung) enthalten.
+ Wenn ein Suchbegriff ein Leerzeichen beinhaltet, muss er mit Anführungszeichen umrandet werden: "Begriff1 mit Leerzeichen" Begriff2. +

+{% endblock %} diff --git a/templates/documentation-syntax-internal.html b/templates/documentation-syntax-internal.html new file mode 100644 index 0000000000000000000000000000000000000000..eca91c5589ae81d6a87edab4dc09217e85c7df21 --- /dev/null +++ b/templates/documentation-syntax-internal.html @@ -0,0 +1,63 @@ +{% extends "documentation-base.html" %} +{% set active_page = "internal_syntax_documentation" %} +{% block title %}Syntax: Interne Abschnitte{% endblock %} + +{% block documentation_content %} +

Syntax: Interne Abschnitte

+ {% if config.PRIVATE_KEYWORDS %} +

+ Das Protokollsystem ermöglicht es, in einem Protokoll bestimmte Abschnitte als nicht-öffentlich/intern zu kennzeichnen. Diese Abschnitte werden nur in der internen pdf-Datei gedruckt und nur internen Personen angezeigt - wer das ist lässt sich im System explizit festlegen. Die öffentliche Version des Protokolls enthält dann an betroffenen Stellen einen Hinweis, dass es hier einen internen Abschnitt gibt. Aus Gründen der Transparenz bietet es sich an, vor oder nach dem internen Protokollieren dessen Inhalt zusammenzufassen. +

+

+ Beschlüsse sind im Protokollsystem immer öffentlich, daher ergibt es keinen Sinn diese in einem internen Abschnitt zu protokollieren. +

+

Definition

+
+
+

+ Der interne Abschnitt wird eingeleitet mit einem der folgenden Wörter ({{config.PRIVATE_KEYWORDS|map("code_key")|join(" ")|safe}}) gefolgt von den üblichen geschweiften Klammern { ... } einer Liste. Zwischen den Klammern wird wie gewöhnlich protokolliert. +

+
+
+
Beispiel - Interner Bereich
+
+
+ 
{TOP Tagesordnungspunkt
+	Dieser Punkt ist öffentlich.
+	{{config.PRIVATE_KEYWORDS[0]}} {
+		Dieser Punkt ist intern.
+		Dieser auch, wir diskutieren Kritik an einem namentlich genannten Professor und seiner Vorlesung.
+		Hier entwickeln wir eine Strategie.
+	}
+	Dieser ist wieder öffentlich.
+	Es wurde die Kritik an einer Vorlesung kritisiert.
+}
+
+
+
+
+
+
+
Zu beachten
+
+
+

+ Ein interner Abschnitt kann keinen Titel haben. Stattdessen wird der Titel durch das entsprechende Schlüsselwort ersetzt. +

+
+
+
+
+ {% else %} +
+
+
Nutzung nicht vorgesehen
+
+
+

+ Die Verwendung von internen Abschnitte ist hier bisher noch nicht vorgesehen. Um interne Abschnitte nutzen zu können, wende dich bitte an die Admins und lasse die Konfiguration durch sie entsprechend anpassen. +

+
+
+ {% endif %} +{% endblock %} diff --git a/templates/documentation-syntax-lists.html b/templates/documentation-syntax-lists.html new file mode 100644 index 0000000000000000000000000000000000000000..9f1d1d7bf4317fbce0a7d6204d5feb88e99b19d5 --- /dev/null +++ b/templates/documentation-syntax-lists.html @@ -0,0 +1,72 @@ +{% extends "documentation-base.html" %} +{% set active_page = "lists_syntax_documentation" %} +{% block title %}Syntax: Listen{% endblock %} + +{% block documentation_content %} +

Syntax: Listen

+

+ Das Protokollsystem sieht vor, dass Diskussionen in einem Tagesordnungspunkt strukturiert und in Unterpunkte aufgeteilt werden können. Dies wird durch sogenannte Listen umgesetzt. Mit jedem Zeilenumbruch erzeugt das Protokollsystem beim Kompilieren (Übersetzten des Syntax in ein PDF oder die Webseitenanzeige) einen neue Zeile im fertigen Protokoll und setzt ggf. ein Auszählungszeichen an den Anfang der Zeile. +

+

+ Zusätzlich gibt es im Protokollsystem spezielle Listen, die es ermöglichen hinsichtlich der Ausgabe oder des Titels Unterscheidungen vornehmen zu können. {% if config.PRIVATE_KEYWORDS|length > 0 %}Diese Listen sind{% else %}Eine solche Liste ist{% endif %} der Tagesordnungspunkt{% if config.PRIVATE_KEYWORDS|length > 0 %} und der interne Abschnitt{% endif %}. +

+

Definition

+
+
+

+ Die Liste ist im Protokoll das strukturierende Element. Es beginnt und endet mit einer geschweiften Klammer. Die Elemente der Liste werden durch das Zeilenende getrennt. Es ist möglich Listen beliebig ineinander zuschachteln. Zusätzlich kann eine Liste einen Titel haben, der vor der öffnenden Klammer { steht. +

+
+
+
Syntax einer Liste
+
+
+ 
Titel der Liste {
+    Details zu diesem Punkt.
+    Mehr Details zu diesen Punkt in einer neuen Zeile.
+}
+
+
+
+
+
+
+
Zu beachten
+
+
    +
  • Spezielle Listen weisen hinsichtlich des Titels ein anders Verhalten auf.
    • +
  • Listen in der höchsten Ebene müssen TOPs sein.
    • +
+
+
+
+
+
+
Beispiel - Verschachtelte Listen
+
+
+ 
{TOP Bericht
+	Es wird über die Aktivitäten seit der letzten Sitzung berichtet.
+	Erstsemesterarbeit{
+		Die Vorbereitung für die nächste Erstsemesterwoche laufen. Ab dieser Woche werden auch wieder regelmäßige Planungstreffen stattfinden.
+	}
+	Infrastruktur{
+		Es fand ein Treffen statt auf dem aktuelle Projekte besprochen wurden. 
+		Wasserspender{
+			Es wurden Vorschläge für Aufstellorte von weiteren Wasserspendern gemacht.
+			Weiteres wird geprüft.
+		}
+		Luftpumpen{
+			Es sollen Luftpumpen angeschafft werden.
+			Ein Angebot wird eingeholt
+		}
+		Renovierung{
+			Eine Renovierung ist geplant.
+			Anforderungen sollen gesammelt werden.
+		}
+	}
+}
+
+
+ +{% endblock %} diff --git a/templates/documentation-syntax-meta.html b/templates/documentation-syntax-meta.html new file mode 100644 index 0000000000000000000000000000000000000000..b69b51230980693eb80436d864418adba61266f4 --- /dev/null +++ b/templates/documentation-syntax-meta.html @@ -0,0 +1,22 @@ +{% extends "documentation-base.html" %} +{% set active_page = "meta_syntax_documentation" %} +{% block title %}Syntax: Metadaten{% endblock %} + +{% block documentation_content %} +

Syntax: Metadaten

+

+ In einem Protokoll repräsentieren die Metadaten allgemeine Informationen rund um eine Sitzung. Die Metadaten stehen immer am Anfang eines Protokolls. Zu den Metadaten zählen das Datum der Sitzung, der Beginn und das Ende sowie weitere pro Protokolltyp konfigurierte Metadatenfelder, wie beispielsweise der Ort, die Anwesenden oder die Protokollführung. Alle Metadatenfelder werden beim Erzeugen der Protokollvorlage durch das System automatisch in das Protokoll übertragen. Dies schließt auch den Inhalt der Felder ein, so weit dieser vor Beginn der Sitzung eingegeben wurde. +

+

Definition

+

+ Die Syntax der Metadaten ist #Name;Wert und die einzelnen Felder und Einträge werden durch Zeilenumbrüche getrennt. Weiterhin darf auf das Semikolon kein Leerzeichen folgenden, da dies zu einem nicht kompilierbaren Protokoll führt. Auch müssen die folgende Metadaten immer in diesem Format angegeben werden, da eine Interpretation des Datums und der Uhrzeit sonst fehlschlägt. +

+ +

+ Wurden Metadatenfelder im Protokolltyp konfigurierte so muss als Name der festgelegte Key verwendet werden. Dabei muss die Groß- und Kleinschreibung beachtet werden. +

+{% endblock %} diff --git a/templates/documentation-syntax-tags.html b/templates/documentation-syntax-tags.html new file mode 100644 index 0000000000000000000000000000000000000000..4e0b41c0e5749a1bd5155e4d14076e416b88b56b --- /dev/null +++ b/templates/documentation-syntax-tags.html @@ -0,0 +1,149 @@ +{% extends "documentation-base.html" %} +{% set active_page = "tags_syntax_documentation" %} +{% block title %}Syntax: Tags{% endblock %} + +{% block documentation_content %} +

Syntax: Tags

+

+ Sollen in einem Protokoll Texte hervorgehoben oder in einer anderen Art und Weise formatiert werden, so bietet das Protokollsystem sogenannte Tags. Jeder Tag steht dabei stets in einer eigenen Zeile des Protokolls. Mit diesen Tags können neben einer veränderten Ausgabe des Textes auch bestimmte Aktionen im Protokollsystem ausgeführt werden. +

+

Definition

+
+
+

+ Grundsätzlich wird jeder Tag in eckige Klammern eingeschlossen. Eingeleitet wird ein Tag nach der öffnenden eckigen Klammer [ mit dem Namen des Tags. Mit Semikolons getrennt, folgen theoretisch beliebig viele Argumente, wobei je nach Tag-Typ nur endlich viele Argumente eine Bedeutung haben. Jeder Tag wird als einzelnes Element einer Liste interpretiert. +

+
+
+
Syntax eines Tags
+
+
+ 
[Typ;Argument 1;Argument 2;…]
+
+
+
+
+
+
+
Verfügbare Typen
+
+
+ +
+
+
+
+ +

URL-Tag

+

+ Sollen URLs oder Hyperlinks in einem Protokoll dargestellt werden, so kann und sollte der Tag vom Typ url genutzt werden. Als einziges Argument wird im Tag die URL angegeben.{% if config.ETHERPAD_ACTIVE %} Ein Leerzeichen am Ende des Arguments ist nicht notwendig für das Protokollsystem, erleichtert aber das Anklicken im Etherpad.{% endif %} +

+
+ 
[url;https://protokolle.fsmpi.rwth-aachen.de ]
+
+ +

Beschluss-Tag

+ {% if config.PRIVATE_KEYWORDS|length > 0 %} +
+
+ {% endif %} +

+ Werden in einer Sitzung Beschlüsse gefasst, so bietet sich die Nutzung des Tags beschluss an. Ein Beschluss wird so im Protokoll zum einen als Beschluss gekennzeichnet und zum andern zusätzlich am Anfang des Protokolls angezeigt. Auch werden die Beschlüsse in der Beschlussdatenbank gespeichert und sind online durchsuchbar{% if config.PRINTING_ACTIVE %} sowie einzeln ausdruckbar{% endif %}. +

+
+ 
[beschluss;Beschlusstext;Beschlusskategorie 1;Beschlusskategorie 2;…]
+
+ {% if config.PRIVATE_KEYWORDS|length > 0 %} +
+
+
+
+
Zu beachten
+
+
Beschluss-Tags dürfen nicht in internen Abschnitten stehen.
+
+
+
+ {% endif %} +

+ Ein Beschluss kann mit Beschlusskategorien versehen werden, um Beschlüsse zu einzelnen Themen zusammenfassen zu können. Des Versehen mit Kategorien ist jedoch kein muss. Kategorien müssen vor der Verwendung in den Einstellungen des Protokolltyps definiert werden. Danach können Beschlüsse durch die Angabe der Kategorie entsprechend zugeordnet werden, z.B. […;finanzwirksam;…]. +

+

+ Es empfiehlt sich Beschlüsse klar, einfach, eindeutig und auch kontextlos verständlich zu formulieren. Sind die Beschlüsse im Rahmen einer Abstimmung ergangen, so empfiehlt es sich das Abstimmungsergebnis am Ende des Beschlusses in der Form (Ja/Nein/Enthaltung) anzugeben. +

+
+
+
Beispiel - Beschluss-Tag
+
+
+ 
[beschluss;Wir beschaffen für bis zu 100,00 € einen Stuhl.(9/1/3);finanzwirksam;Inventar]
+
+
+ +

Todo-Tag

+

+ Soll in einer Sitzung die Vergebene einer Aufgabe an eine oder mehrere Personen (oder AG, AK, …) festgehalten werden, so kann mittels des Tags todo diese Aufgabe im Protokoll festgehalten werden. Neben dem Namen der Person, welche die Aufgabe erledigen möchte, wird die Aufgabe innerhalb des Tags festgehalten. Die Aufgabe ist nach der Sitzung in der Todo-Übersicht und nur im internen Protokoll einsehbar. +

+
+ 
[todo;Name;Aufgabe;Argument 1;Argument 2;…]
+
+

+ {% if config.MAIL_ACTIVE %}Wurde der Name einer Mail zugeordnet, so wird diese Person (oder AG, AK, …) per Mail über ihre offenen Todos nach einer Sitzung informiert. {% endif %}Bei der Angabe mehrerer Personen können diese durch Leerzeichen oder Kommata voneinander getrennt angegeben werden. +

+

+ Eine bereits bestehende und noch offene Aufgabe wird automatisch in ein neues Protokoll eingefügt, wenn der TOP „Todos“ auf der Tagesordnung steht (der TOP also im Protokoll enthalten ist). Zusätzlich erhält die Aufgabe dann als optionales Argument eine ID: […;id 1338]. Wird dieser Todo dann während des Protokollierens geändert, passiert das auch im Protokollsystem. +

+

+ In einem weiteren optionalen Argument kann außerdem der Status einer Aufgabe, z.B. […;done;…] angegeben werden. Die Groß- und Kleinschreibung spielen bei der Verwendung keine Rolle. Wenn der Status ein Datum benötigt, muss dieser immer mit angegeben und hat die Form: […;dd.mm.yyyy;…]. Bei der Angabe des Datums ist es unerheblich, an welcher Stelle innerhalb des Tags es auftacht. Eine Auflistung der verwendbaren Status-Begriffe und ob Status ein Datum benötigt, ist in der folgenden Tabelle angegeben. +

+ + + + + + + + + + {% for state, posibilities in states.items() %} + + + + + + {% endfor %} + +
StatusBenötigt DatumVerwendbare Status-Begriffe
{{state.get_name()}}{{posibilities|map("code_key")|join(", ")|safe}}
+
+
+
Beispiele - Todo-Tag
+
+
+ 
[todo;mmustermann;Planung für die ESA beginnen;ab;01.03.2018]
+[todo;mmustermann;Mit der Fakultät treffen]
+[todo;kmusterfrau;Organisiation des nächsten Events;in Bearbeitung;id 1]
+
+
+ +

Fußnoten-Tag

+

+ Ist es erforderlich, dass Informationen als Fußnote im Protokoll aufgeführt werden sollen, so können diese im Protokoll mit dem Tag des Types footnote geschrieben werden. Als einziges Argument wird der Inhalt der Fußnote übergeben. +

+
+ 
[footnote;Inhalt]
+
+ +

Sitzungs-Tag

+

+ Werden während einer Sitzung bereits Termine für zukünfigt Sitzungen desselben Typs festgelegt, so können diese direkt aus dem Protokoll heraus angelegt und im Protokoll entsprechend hervorgehoben werden. Es wird der Tag des Types sitzung genutzt. Als Argument muss mindestens das Datum übergeben werden und es hat die Form: […;dd.mm.yyyy;…]. Optional kann zusätzlich eine Uhrzeit in folgender Form angegeben werden: […;h:mm]. +

+
+ 
[sitzung;Datum;Uhrzeit]
+
+{% endblock %} diff --git a/templates/documentation-syntax-top.html b/templates/documentation-syntax-top.html new file mode 100644 index 0000000000000000000000000000000000000000..f94a09fbab66da40b59658c33e801c1fd6b38ad1 --- /dev/null +++ b/templates/documentation-syntax-top.html @@ -0,0 +1,43 @@ +{% extends "documentation-base.html" %} +{% set active_page = "top_syntax_documentation" %} +{% block title %}Syntax: Tagesordnungspunkte{% endblock %} + +{% block documentation_content %} +

Syntax: Tagesordnungspunkte

+

+ Ein wichtiges Elements in jedem Protokoll sind Tagesordnungspunkte. Sie sind in einem Protokoll stehts die oberste Gliederungsebene. In den meisten Fällen stehen diese Punkte bereits vor Beginn der Sitzung fest und wurden entsprechend vorher eingepflegt. +

+

+ Beim Erstellen der Protokollvorlage durch das System werden die bereits angelegten TOPs mit dem vorprotokollierten Inhalt in der Tagesordnung festgelegten Reihenfolge übertragen. Während des Schreibens des Protokolls können jeder Zeit Tagesordnungspunkte hinzugefügt oder entfernt werden. +

+

Definition

+
+
+

+ In Protokollsystax wird ein Tagesordnungspunkt stets von geschweiften Klammern eingeschlossen. An die öffnende Klammer schließt sich das Schlüsselwort TOP an. Abgesetzt mit einem Leerzeichen folgt der Titel des TOPs. Nach einem Zeilenumbruach als in einer neuen Zeile beginnt dann der Inhalt des Tagesordnungspunkts. Durch die Verwendung von sogenannten Listen kann die Mitschrift in einem Tagesordnungspunkt strukturiert werden. +

+
+
+
Syntax eines Tagesordnungspunkts
+
+
+ 
{TOP Titel des Tagesordnungspunkts
+    Hier steht der Inhalt des Tagesordnungspunkts
+}
+
+
+
+
+
+
+
Zu beachten
+
+
+

+ Innerhalb eines Tagesordnungspunkts kann es keinen weiteren Tagesordnungspunkt geben. +

+
+
+
+
+{% endblock %} diff --git a/templates/documentation-syntax.html b/templates/documentation-syntax.html new file mode 100644 index 0000000000000000000000000000000000000000..5a15a4513535bf2f84a3bcc0b8f2edb99c44d8af --- /dev/null +++ b/templates/documentation-syntax.html @@ -0,0 +1,30 @@ +{% extends "documentation-base.html" %} +{% set active_page = "syntax_documentation" %} +{% block title %}Syntax{% endblock %} + +{% block documentation_content %} +

Syntax

+

+ Das Herz des Protokollsystems ist die eigentliche Protokollsyntax, aus dem systemintern ein druckbares Dokument und menschenlesbarer Webseiteninhalt erstellt wird. Die Systax sieht eine Strukturierung des Prokolls vor. Ein Dokument beginn mit einigen Metadaten, danach kommen nacheinander die Tagesordnungspunkte, die strukturiert diskuiterte Punkte enthalten. Darüberhinaus gibt es Tags, mit denen unter anderem URLs, Beschlüsse oder ToDos markiert werden können. +

+

Allgemeine Grundsätze

+

+ Hast du zum ersten Mal Kontakt mit dem Protokollsystem so sind sollten die folgenden Grundsätze beachtet werden, damit die erfolgreiche Erstellung eines Protokolls einfach gelingt. +

+ +

Der Syntax im Detail

+

+ Um die Funktionsweise und das Verhalten des Protokollsystems bei der Umwandlung eines Protokolls zu verstehen, wird auf den Unterseiten auf die einzelnen Elemente der Protokollsyntax näher eingegangen. +

+ +{% endblock %} diff --git a/templates/documentation.html b/templates/documentation.html index fd539659aa1c8805ff88fe6d9cd52dd0aadb4c60..488e58450511a2d555d42b56b2faa8ee7087c862 100644 --- a/templates/documentation.html +++ b/templates/documentation.html @@ -1,224 +1,51 @@ -{% extends "layout.html" %} -{% from "macros.html" import render_table %} +{% extends "documentation-base.html" %} +{% set active_page = "documentation" %} {% block title %}Dokumentation{% endblock %} -{% block content %} -
-
-

Protokollsystem

- Das Protokollsystem dient der Planung von Sitzungen und Verwaltung von Protokollen. Die anstehenden Sitzungen der nächsten Woche sind auf der Startseite, alle Protokolle unter Protokolle zu finden. -

Sitzungsplanung

- Sollte das Protokoll noch nicht existieren: -
    -
  1. Gehe auf Neu
    2. -
  2. Wähle bei „Typ“ den Typ der Sitzung aus.
    3. -
  3. Gib das Datum der Sitzung ein.
    4. -
  4. Anlegen
    5. -
- Wenn es existiert: -
    -
  1. Gehe auf Protokolle
    2. -
  2. Wähle die Sitzung aus. Noch ausstehende Sitzungen sind ganz oben. -
- Auf der Seite der Sitzung siehst du die Tagesordnung. - -

Wie schreibe ich eine Protokoll?

- Die folgenden Schritte werden erst ein paar Minuten vor der Sitzung ausgeführt. Vorher werden Inhalte und TOPs wie oben beschrieben vorprotokolliert. -
    -
  1. Protokoll auswählen (s.o.)
    2. -
  2. mit „In Etherpad“ die Vorlage in das Etherpad schreiben.
    3. -
  3. mit „Etherpad“ das Etherpad öffnen
    4. -
  4. verlese Tagesordnung und Todos
    5. -
  5. falls Todo erledigt, markiere als erledigt (Details siehe Todos
    6. -
  6. schreibe das Protokoll im Etherpad
    7. -
  7. Importiere das Protokoll am Ende mit „Aus Etherpad“
    8. -
  8. Falls Fehler auftreten, behebe sie (siehe Fehler
    9. -
  9. Wenn keine Fehler mehr auftreten, drucke das Protokoll mit „Löschen” (unten beim Anhang) aus.
    10. -
  10. Korrekturlesen lassen und im Etherpad korrigieren, dann nochmal „aus Etherpad“
    11. -
  11. Drucken und abheften
    12. -
  12. Intern per Mail versenden
    13. -
  13. Korrekturen abwarten (z.B. die Genehmigung auf der nächsten Sitzung)
    14. -
  14. Veröffentlichen (und ggf. öffentlich versenden)
    15. -
-
Höchst interne Protokolle
- Falls das Protokoll Daten beinhaltet, die auf keinen Fall öffentlich sein sollten (z.B. personenbezogene Daten bei einem Sozialausschuss), kann anstelle des Editierens im Etherpad auch mit „Vorlage“ die leere Protokollvorlage heruntergeladen werden. Darin kann lokal mit einem beliebigen Texteditor die Sitzung protokolliert werden, um sie dann am Ende lokal zu speichern und mit „Quellcode hochladen“ hochzuladen. -

Was, wenn etwas nicht funktioniert?

+{% block documentation_content %} +

Protokollsystem 3 - Das Protokollsystem

+

+ Das Protokollsystem dient der Planung von Sitzungen und Verwaltung von Protokollen. Die anstehenden Sitzungen der nächsten Woche sind auf der Startseite, alle Protokolle unter Protokolle zu finden. +

+

+ Des weiteren können die Sitzungen mittels Todos und einer Beschlussdatenbank nach verfolgt werden. Die eigenen offenen Todos werden auf der Startseite angezeigt, alle Todos sind unter Todos zu finden. Die Beschlüsse finden sich in der Beschlussdatenbank. +

+

Dokumentation

+ Dieser Dokumentation können Beschreibungen zu nahezu allen wichtigen Systemfunktionen entnommen werden. Gegliedert sind die Themen wie folgt: + +

+ Sollten deine Fragen nach dem Studium der Dokumentation noch offen sein, wende dich an jemand erfahreneren oder die Admins. Offene Punkte innerhalb der Dokumentation können dann durch die Admins zur Behebung auch an die Entwickler der Software weitergegeben werden. +

+

Fehlerbehandlung

-

Todosystem

- Das Protokollsystem verwaltet Todos über mehrere Protokolle hinweg. Offene Todos werden in die Protokollvorlage eingefügt, falls diese einen TOP „Todos“ beinhaltet. - - -

Suche

- Protokolle, Todos und Beschlüsse können durchsucht werden. - Im Suchfeld können mehrere durch Leerzeichen getrennte Suchbegriffe angegeben werden: Begriff1 Begriff2. - Angezeigt werden alle Ergebnisse, die jeden der Suchbegriffe (unabhängig von Groß- oder Kleinschreibung) enthalten. - Wenn ein Suchbegriff ein Leerzeichen beinhaltet, muss er mit Anführungszeichen umrandet werden: "Begriff1 mit Leerzeichen" Begriff2. - -

Rechteverwaltung

- Das Protokollsystem hat ein Konzept von Rechteverwaltung, dass auf den Benutzergruppen im LDAP basiert. - Rechte werden pro Protokolltyp eingestellt. - Die vorhandenen Rechtestufen sind „Darf öffentliche Version einsehen“, „Darf interne Version einsehen“, „Darf Ändern“ und „Darf Protokolltyp bearbeiten“. - Jedes Protokoll hat eine öffentliche Gruppe, eine interne Gruppe, eine Bearbeitungsgruppe, eine Verwaltungsgruppe und eine Einstellung, ob es öffentlich ist.
- - Die öffentliche Version einsehen dürfen: - - Die interne Version einsehen dürfen: - - Das Protokoll bearbeiten dürfen: - - Die Einstellungen des Protokolltyps bearbeiten und das Protokoll veröffentlichen dürfen: - - - Vom Protokoll wird eine interne und eine öffentliche Version generiert, falls es Inhalte gibt, die nur intern sind. - Todos sind generell intern, Beschlüsse sind generell öffentlich (d.h. einsehbar, wenn man das Recht „Darf öffentliche Version sehen“ hat). - Daher dürfen Beschlüsse nicht in einem internen Teil des Protokolls sein. -
-
-

Syntax

- Ein Dokument beginn mit einigen Metadaten, danach kommen nacheinander die Tagesordnungspunkte, die durch Listen strukturiert sind. - Darüberhinaus gibt es Tags, mit denen URLs, Beschlüsse oder ToDos markiert werden können. - -

Metadaten

- Die Syntax der Metadaten ist #Name;Wert und die einzelnen Einträge werden durch Zeilenumbrüche getrennt. Folgende Metadaten müssen immer in diesem Format angegeben werden: - - Zusätzlich können pro Protokolltyp weitere Metadatenfelder konfiguriert werden, beispielsweise der Ort, die Anwesenden Teilnehmer, die Protokollführung, …. Diese haben als Wert beliebigen Text. -

Tagesordnungspunkte

- Ein TOP besteht aus einem Titel und beliebigem Inhalt. - Ein TOP ist eine besondere Liste (s.u.) und kann somit wie diese verwendet werden. -
-{TOP Tagesordnungspunkt
-    Inhalt:
-}
-
-

Liste

- Die Liste ist das einzige strukturierende Element. - Listen können beliebig geschachtelt werden. - Die Elemente der Liste werden durch das Zeilenende getrennt. -
-{TOP Tagesordnungspunkt
-    Zeile mit Text drin
-    Hier eine geschachtelte Liste: {
-        Details zu diesem Punkt.
-        Mehr Details zu diesen Punkt.
-    }
-}
-
- - Text, der vor der öffnenden Klammer { steht, wird als Name der Liste angesehen, nur TOPs können Text hinter der öffnenden Klammer haben. - Listen in der höchsten Ebene müssen TOPs sein. -{% if config.PRIVATE_KEYWORDS|length > 0 %} -

Interne Abschnitte

- Wenn der Name einer Liste (bis auf Leerzeichen und einen optionalen :) eins aus - {{config.PRIVATE_KEYWORDS|map("code")|join(" ")|safe}} - ist, ist diese Liste intern. - Daher wird sie nur in der internen Version des Protokolls angezeigt. - In der öffentlichen Version steht stattdessen nur ein Hinweis auf diese interne Stelle. - Es bietet sich beim Protokollieren an, wenn nach dem internen Bereich kurz dessen Inhalt zusammengefasst wird (natürlich nur sofern dies geht ohne die Interna zu verraten), oder begründet wird, warum dies intern ist. -
-{TOP Tagesordnungspunkt
-    Dieser Punkt ist öffentlich.
-    {{config.PRIVATE_KEYWORDS[0]}}: {
-        Dieser Punkt ist intern.
-        Dieser auch, wir diskutieren Kritik an einem namentlich genannten Professor und seiner Vorlesung.
-        Hier entwickeln wir eine Strategie.
-    }
-    Dieser ist wieder öffentlich.
-    Es wurde die Krtik an einer Vorlesung kritsiert.
-}
-
-

Tags

- Tags können Text besonders hervorheben oder bestimmte Aktionen ausführen. - Die grundsätzliche Syntax ist [Name;Arg1;Arg2;…], wobei theoretisch beliebig viele Argumente angegeben werden können, allerdings je nach Typ nur endlich viele eine Bedeutung haben. -
URL-Tag
- Mittels [url;https://protokolle.fsmpi.rwth-aachen.de ] kann ein entsprechend formatierter Link eingebunden werden. - Das Leerzeichen am Ende ist nicht notwendig für das Protokollsystem, erleichtert aber das Anklicken im Etherpad. -
Beschluss-Tag
- [beschluss;Wir beschließen etwas tolles.] erzeugt einen Beschluss im Protokoll. - Ein Beschluss wird zusätzlich am Anfang des Protokoll angezeigt. - Die Beschlüsse sind online durchsuchbar. - Beschluss-Tags dürfen nicht in internen Abschnitten stehen. - Falls für den Protokolltyp Beschlusskategorien definiert sind, können Beschlüsse mit […;finanzwirksam;…] diesen zugeordnet werden. - Beschlüsse können nach Beschlusskategorien gefiltert werden. - Es empfiehlt sich Beschlüsse klar, einfach, eindeutig und auch kontextlos verständlich zu formulieren. - Sind die Beschlüsse im Rahmen einer Abstimmung ergangen, so empfiehlt es sich das Abstimmungsergebnis am Ende des Beschlusses in der Form (JA/NEIN/ENTHALTUNG) anzugeben. [beschluss;Wir beschaffen für bis zu 100,00 € einen Stuhl.(9/1/3);finanzwirksam;Inventar] -
Todo-Tag
- In den Protokollen können Todos verwaltet werden. - Ein neuer Todo wird mit [todo;Name;Aufgabe] angelegt. - Dieser ist dann online und in den Mails sichtbar. - Falls der Name einer Mail zugeordnet ist, wird diese Person (oder AG, AK, …) per Mail über ihre offenen Todos informiert. - Mehrere Personen können durch Leerzeichen oder Kommata getrennt angegeben werden. - - Ein bereits bestehender Todo wird mit der zusätzlichen Option […;id 1338] in ein neues Protokoll eingefügt, falls es den TOP „Todos“ beinhaltet.. Wird dieser Todo dann geändert, passiert das auch im Protokollsystem. - Außerdem kann der Status des Todos, z.B. […;done;…] angegeben werden. - Wenn der Status ein Datum benötigt - ({{todostates|select("needs_date")|map("todo_get_name")|join(", ")}}) - muss dies als […;dd.mm.yyyy;…] angegeben werden. -
- Folgende Begriffe werden vom Protokollsystem verstanden (Groß- und Kleinschreibung spielt keine Rolle): - -
Fußnoten-Tag
- Fußnoten können im Protokoll mit [footnote;Inhalt] geschrieben werden. -
Sitzungs-Tag
- Aus dem Protokoll können neue Sitzungen desselben Typs mit dem Tag [sitzung;Datum], z.B. [sitzung;24.12.2017] angelegt werden. - Optional kann zusätzlich eine Uhrzeit angegeben werden: [sitzung;Datum;Uhrzeit] (z.B. [sitzung;01.01.2018;9:00]). - -{% endif %} {% if git_revision %}

Version

- Dieses Protokollsystem nutzt die Software „Protokollsystem 3“ in der Version vom {{git_revision.date|datify}}. +

+ Dieses Protokollsystem nutzt die Software „Protokollsystem 3“ in der Version vom {{git_revision.date|datify}}.
Alle Änderungen, die seitdem hinzugekommen sind, kannst du hier sehen. +

{% endif %} -
-
{% endblock %}