Janneck
Erstellte Forenantworten
-
Beiträge
-
Hallo,
Anknüpfend an den Thread Korrektur struktureller Fehler:
Wie kann ich denn die Gruppierungsnummer einer Gruppierung (auf der ich nur Org-Admin-Rechte habe) abfragen? Beim Laden des Gruppierungsbaumes (z. B. in der Mitgliederverwaltung) werden nur zwei Felder übertragen: die ID und eine Kombination aus Gruppierungsname und -nummer. Meine momentane Lösung parst die Gruppierungsnummer mit einem regulären Ausdruck aus diesem Feld. Gibt es da auch eine ordentliche Lösung, mit der man die Gruppierungsnummern direkt als JSON abfragen kann?
Viele Grüße,
FabianHi,
das Problem mit den Gruppierungsnummern/-IDs war denke ich, dass es anfangs kein anderes Feld gab, aus dem man die Gruppierungsnummer auslesen konnte (vgl. Thread ). Deswegen hatte ich da einfach die Gruppierungs-ID verwendet, als ich angefangen habe auf die API zuzugreifen.
Ich bin mittlerweile aber auch dazu übergegangen die IDs nur intern zu verwenden und zur Suche nur noch Mitgliedsnummern zu verwenden.
Zu den Telefonnummern: Wollte es nur mal erwähnt haben. Hätte für mich aber auch eine sehr niedrige Priorität.
Viele Grüße,
FabianHallo,
wir haben in der AG auch versucht, nachzuvollziehen, warum es dafür Leserechte braucht.
Ich habe es so verstanden, dass NaMi von seiner Rechtestruktur her verlangt, dass man in irgendeiner Gruppierung Rechte hat, um das Interface sinnvoll zu nutzen. Die Gruppierungsebenen sind dabei Bund/Diözese/Bezirk/Stamm/(Siedlung)
Was da noch fehlen würde wäre die Gruppierungsebene „Mitglied/Nur meine eigenen Daten“. Das geht aber so noch nicht, daher der „Workaround“ über die Leserechte.
Der andere Grund war, dass seinerzeit einzelne Personen im Bundesamt davon ausgegangen sind, dass es ohnehin der Normalfall wäre, dass alle Leiter im Stamm Leserechte haben.Ich war mit dieser Situation auch nicht so zufrieden. Nachdem erste Gespräche nicht so erfolgreich waren, gab es am 18.2.2015 einen Beschluss im Hauptausschuss mit 2 Forderungen:
1.: die Vorstände erhalten in Listenform Zugriff auf die Einsichtnahmen ihrer Mitglieder (also in der einfachen Form: Name / Vorname / Geburtsdatum / Datum der Einsichtnahme)
–> Hier ist eine Lösung in Sicht, die interconcept für uns kostenneutral realisiert: es soll bis Ende Q2/2015 gruppierungsspezifische Berichte geben. Darüber können wir dann diesee Liste und aber auch andere Auswertungen direkt aus der Datenbank ziehen und den Gruppierungen zur Verfügung stellen.
2.: Alle Mitglieder sollen ihr Führungszeugnis einrichen und die Bescheinigung herunterladen können, ohne irgendwo Rechte haben zu müssen.
–> Dafür braucht es eine andere Lösung: Eine Webanwendung mit der alle Mitglieder ihre Kontaktdaten über die DPSG-Webseite ändern können, ist derzeit größtenteils fertig und sollte in den nächsten Monaten online gehen. Dort sollen dann auch diese beiden Funktionen verfügbar sein.Grundsätzlich fände ich es gut, wenn NaMi auch bis zu einem gewissen Punkt „Self-Service“ über die API zulässt. Darüber haben wir mit den Entwicklern schon mal gesprochen. Dafür müsste es dann einen eigenen Satz Methoden geben, die nur für den Self-Service verwendet werden.
Da sind wir auch ein bisschen auf Feedback aus der Entwicklergemeinde angewiesen. Was haltet Ihr von so einem Self-Service-Modus? Seht Ihr Anwendungen dafür?Damit das funktioniert müssten wir halt erst die Authentifizierung umstellen, damit nicht für jeden Benutzer API-Rechte notwendig sind. Da stellen wir nach der Bundesversammlung mal unsere bisherigen Ideen Online um diese mit Euch zu diskutieren. Ggf. fällt dabei auch eine SSO-Infrastruktur mit ab (so in Richtung SAML/OpenID/OAuth2).
Viele Grüße & Gut Pfad
Daniel
(AG NCM)Aus dem Thread Einsichtnahme Führungszeugnisse ohne Leserechte
Dafür braucht es eine andere Lösung: Eine Webanwendung mit der alle Mitglieder ihre Kontaktdaten über die DPSG-Webseite ändern können, ist derzeit größtenteils fertig und sollte in den nächsten Monaten online gehen. Dort sollen dann auch diese beiden Funktionen verfügbar sein.
Grundsätzlich fände ich es gut, wenn NaMi auch bis zu einem gewissen Punkt “Self-Service” über die API zulässt. Darüber haben wir mit den Entwicklern schon mal gesprochen. Dafür müsste es dann einen eigenen Satz Methoden geben, die nur für den Self-Service verwendet werden.
Da sind wir auch ein bisschen auf Feedback aus der Entwicklergemeinde angewiesen. Was haltet Ihr von so einem Self-Service-Modus? Seht Ihr Anwendungen dafür?Damit das funktioniert müssten wir halt erst die Authentifizierung umstellen, damit nicht für jeden Benutzer API-Rechte notwendig sind. Da stellen wir nach der Bundesversammlung mal unsere bisherigen Ideen Online um diese mit Euch zu diskutieren. Ggf. fällt dabei auch eine SSO-Infrastruktur mit ab (so in Richtung SAML/OpenID/OAuth2).
Finde ich eine super Idee!
Riesen Vorteile:
– Entlastung des NaMiAdmins (dieser sollte aber eine Benachrichtigung erhalten können)
– Lösung eines Problems von uns:Leiter ist ursprünglich aus einem anderen Stamm. Ich kann die Adresse nicht ändern, da er bei uns nur „blau“ ist, aber der eigentliche Stamm exisitiert nur noch leidlich und NaMi wird nicht gepflegt.
Schön, dass es da endlich eine Lösung in Sicht ist.
Die informelleselbst Bestimmung sehe ich bei der „Listenform“ geward, da man ja selbst sein Führungszeugnis an die Bundesebene schickt. Die Information „ist noch nicht geschickt“ die man so erhält sehe ich nicht als besonders kritisch, ob der Leiter jetzt sagt er hats noch nicht geschickt oder er hat die Bestätigung noch nicht runtergeladen hat das selbe Ergebnis.
Aber man gewinnt durch die Listenform die Möglichkeit die Abwicklung für wenig computeraffine zu erleichtern.
Zum Selfservice
Habe ich einen eigenen Thread eröffnet.@daniel:
Ja man könnte das mit Präfix machen, aber jeder Stamm hat da jetzt schon eine eigene Lösung und es braucht auch noch z.B. ein Postfix, dass die Mandate mitzählt (Kontoänderung bei gleicher Mitgliedsnummer).
Werte Datum: Standarddatum; z.B. 12.03.2015
Werte Mandatsref: max. 35 Zeichen, 0–9 A–Z a–z ‚ : ? , – + . ( ) /; z.B. 109090-01
Werte GläubigerID: max. 18 Zeichen, 0–9 A–Z a–z; DE98ZZZ09999999999@fabian:
Ja, man braucht zusätzliche Anwendungen, die man vll auch später noch in NaMi einbetten kann. Aber man hat zumindest schonmal den Vorteil, dass alle Daten für die Generieung an einem zentralen Ort gespeichert werden.
zu Telefonnummern:
Die Bindestrich-Lösung hätte für mich super funktioniert, daran hatte ich einfach nicht gedacht.
Aber „/“ wird mitlerweile tatsächlich erlaubt, sry dass hab ich nicht gemerkt.zu Banknamen:
– 1822 direkt (keine Zahlen erlaubt)
– Sparkasse Miltenberg-Obernburg (kein – erlaubt)
– Raiffeisenbank Großostheim-Elsenfeld (kein ß erlaubt)Fehlermeldung beim Speichern: Der Name des Kreditinstituts muss aus mindestens 4 Zeichen bestehen und darf keine Umlaute, Zahlen und Bindestriche enthalten
zu strukturelle Fehler:
es ist für mich deshalb ein struktureller Fehler, da man direkt am Anfang von „Konzeptionelle Modelierung“ 1. Semester Informatik lernt, dass es Mist ist willkürliche IDs einzuführen. Zumal man eine wunderschöne Mitgliesnummer hat, die meiner Meinung nach als Fremdschlüssel für alles getaugt hätte.Gemeint waren tatsächlich API-Nutzer.
Fabian hat ein Tool entwickelt, mit dem man z.B. ordentliche Statistiken für Diözesen auslesen kann.
Bei der Anfrage zwecks API-Nutzer hieß es vom namisupport, würden grundsätzlich nicht vergeben.Mit der Aussage würde es sich ja nicht lohnen weiter an solchen Tools zu arbeiten, wenn sie eh nicht in die produktive Umgebung dürfen.
Jo, das wäre sinnvoll. Ich würde jetzt mal aus dem Bauch raus sagen: Wenn die Stammessuche auf dpsg.de solche Daten ausgibt, sollte das auch über die API möglich sein. Da müssen wir uns mal die Stammessuche-Extension anschauen wie das dort gelöst ist und welche Rechte es dafür braucht.
Dann kann ich mal versuchen das im Testsystem so nachzustellen, dass du das auch testen kannst. Schreib uns mal einen Reminder an ncm@dpsg.de mit deinem Usernamen / Mitgliedsnummer im Testsystem.
Nur vor der Bundesversammlung wird das leider nichts mehr.Im aufwendigsten aller möglichen Fälle müsste interconcept noch einen Service-Call bauen, mit dem man die „öffentlichen Daten“ der Gruppierungen auslesen kann. Das würden wir dann mit auf die Liste nehmen.
Viele Grüße
DanielIch finde es auch gut, dass da in nächster Zeit eine Lösung kommt. So wie ich das Rechtemodell verstehe, hätte es da auch einen Workaround in NaMi gegeben, aber so ist’s noch besser.
„Der andere Grund war, dass seinerzeit einzelne Personen im Bundesamt davon ausgegangen sind, dass es ohnehin der Normalfall wäre, dass alle Leiter im Stamm Leserechte haben.“
Das hat mich auch sehr irritiert. Insbesondere weil das den Informationen widerspricht, die wir zur Einführung von NaMi 2.0 bekommen haben (da hieß es ausdrücklich, dass man sich überlegen soll, wer überhaupt Leserechte braucht).
Und letztes Jahr hat dann das Bundesamt irgendwann selbst Rechte auf NaMi vergeben, wenn Leute ihre Führungszeugnis-Bescheinigung runterladen wollten.„Damit das funktioniert müssten wir halt erst die Authentifizierung umstellen, damit nicht für jeden Benutzer API-Rechte notwendig sind. Da stellen wir nach der Bundesversammlung mal unsere bisherigen Ideen Online um diese mit Euch zu diskutieren. Ggf. fällt dabei auch eine SSO-Infrastruktur mit ab (so in Richtung SAML/OpenID/OAuth2).“
SSO klingt ja auch spannend. Ich kenn mich damit bisher zwar kaum aus. Aber das wäre schon interessant, wenn man da auch externe Anwendungen dran anbinden könnte.
Was ich mir für den Self-Service vorstellen könnte:
– Anzeige und Bearbeitung der eigenen Stammdaten (Adresse, E-Mail, Telefon, Zeitschriftenversand), aber nicht Bankverbindung, Beitragsart
– Anzeige der eigenen Rechte und Tätigkeiten (aber keine Änderungen daran vornehmen)
– Formulare Führungszeugnis + Bescheinigung Einsichtnahme downloadenMal eine einfache Anregung zum Suchformular (Modul „Suche“): es wäre angenehm, wenn man einfach einen Namen eingeben und die Suche mit der Eingabetaste abschicken könnte. Momentan hat die Eingabetaste keine Funktion.
Im Reiter Mitgliedsverwaltung wäre das setzen eines „selected“ in der Suchkategorie schön.
Ob Vor- oder Nachname ist mir eigentlich egal.
Den Aufwand schätze ich erstmal als gering ein.
Nutzen: – meistens werden 2 Klicks gespart
– für mobile Nutzer wird die Verwendung von katastrophal auf ziemlich katastrophal gesteigert
