Konzept: Userprofile

Damit in der ersten Version erste Einträge gemacht bzw. vorhandene Einträge ergänzt werden können müssen Userprofile angelegt sein.
Es wird ein minimales Userkonzept angewendet / Verzicht auf Organisationsprofile (s. Abstimmung Konzept):

  • alle User können im Community-Prinzip alle Content-Daten für die sie Bearbeitungsrecht haben ändern
  • Wir verzichten in Version 1 auf Organisationsprofile:
    • Organsationen existieren nur als Punkte auf der Karte und sind dort von allen ergänz- und bearbeitbar (genau wie in OpenStreetMaps)
    • perspektivisch: Wenn eine offizielle Emailadresse angegeben ist, können darüber, wenn nötig, Informationen verifiziert werden, z. B.:
      • Organsiationen können als Quelle von anderen Datensätzen verifiziert werden

Userdaten

folgende Userdaten werden bei der Anmeldung von uns erhoben:

Pflicht:

  • Benutzername
  • Passwort
  • Mailadresse / Registrierung per Mail-Bestätigung
  • Zustimmung zu Nutzungsbedingungen

Optional:

  • Kurzbeschreibung (Freitext)
  • Interessen (Autosuggestion, Schlagworte und Kategorien aus der Datenbank)
  • In welcher Region bin ich aktiv?: Auswahlebene: International, Land, Bundesland, Stadt, Stadtteil, Quartier (Mehrfachauswahl möglich)
    • Details zu der Auswahl:
    • User kann angeben, ob er in seinem Quartier, Stadtteil, Stadt, Bundesland, auf Landesebene oder international aktiv ist (User kann z.B. auch in einer anderen Stadt aktiv sein, als die Stadt in der er selbst wohnt, oder in einem Stadtteil einer Stadt und zusätzlich auf NRW Ebene)
    • Er kann z.B. sowohl mehrere Stadtteile, als auch einen (oder mehrere) Stadtteile und das Bundesland (oder andere Kombinationen) angeben. Hierbei wird nicht 'Stadtteil' oder 'Landesebene' angegeben, sondern z.B: 'Elberfeld' oder 'NRW'
    • Vorschlag von Ralf (AP1/2 Treffen 19.06.): Auswahlliste aus OSM boundary:administrativ → Land = Adminlevel2 , Bundesland Adminlevel 4 ... siehe https://wiki.openstreetmap.org/wiki/DE:Grenzen
      (Anmerkung: Screens zu diesem Bereich folgen in der Umsetzungsphase / muss zwischen Jakob/Philip/Alice abgestimmt werden)
    • Nutzungsbeispiel:
      • Ich möchte (perspektivisch) alle Aktiven anschreiben:
        • mit dem Interesse "Sharing" innerhalb NRW  →  Es müssen automatisch alle User angeschrieben werden, die 'NRW' angegeben haben ODER die Quartiere, Städte oder Stadtteile angegeben haben, die in NRW liegen (doppelt anschreiben muss ausgeschlossen sein, Spamschutz wird an anderer Stelle geklärt)
        • mit dem Interesse "Sharing" auf NRW Ebene → Es müssen automatisch alle User angeschrieben werden, die 'NRW' angegeben haben
        • alle Aktiven in Elberfeld → alle User die "Elberfeld" angegeben haben 
        • Christian hätte z. B. angegeben, dass er auf "NRW" Ebene aktiv ist und in "Elberfeld" und würde in jedem der drei Fälle kontaktiert

Userprofil Bereich

Jeder User hat einen Bereich in dem

  • er/sie oben genannte Angaben bearbeiten kann.
  • er/sie Daten von denen er/sie Owner ist einsehen kann
  • perspektivisch: Bearbeitungsrechte dieser Daten ändern kann

Ownership & Quellen Daten

  • jeder Datenpunkt besitzt eine Quelle, Quellen können sein:
    • User gibt an, dass er davon gehört hat 
    • User gibt an, dass er vor Ort war
    • + Freifeld für andere Möglichkeit
    • User gibt an: eigene Datenerhebung (innerhalb einer größeren Erhebung)
      • Erhebungsmethode muss angegeben werden (z. B. Telefoninterview)
    • User gibt an: externe Quelle
      • Quelle muss angegeben werden 
  • User sind für die von Ihnen eingetragene Datenpunkte, geänderte Werte bzw. importierte Datensätze zuständig (Owner)
    • Ownership bedeutet:
      • angemeldete User können einsehen welcher User, wann welche Werte geändert haben (s. 07. Revisionskonzept)
      • User können zu den von Ihnen angelegten/geänderten Werten kontaktiert werden
      • Korrekturen/fehlerhafte Einträge sollen in erster Linie vom Owner korrigiert werden (in der Chronik können Änderungen gesichtet werden und Owner angeschrieben werden)
  • Ownership ist historisch nachvollziehbar für angemeldete User

Rechte Contentdaten- und Userdatenbearbeitung

Es werden vier Nutzergruppen unterschieden:

nicht-angemeldete User:

  • dürfen keine Datenpunkte bearbeiten oder anlegen
  • können auf der Karte dargestellte Daten sehen , Filter- und Suchfunktionen uneingeschränkt nutzen
  • dürfen nicht-personenbeziehbare Content-Daten exportieren → Zustimmung zu Lizenzen vorrausgesetzt 
  • können die Revisionen (Chronik) und Kommentare zu einem Datenpunkt ansehen, die Usernamen, derjenigen, die Kommentare verfasst oder Änderungen vorgenommen haben, sind aber nicht einsehbar (anonymisiert)

angemeldete User:

  • dürfen alles, was nicht-angemeldete User dürfen
  • dürfen alle Daten für die sie Bearbeitungsrecht haben bearbeiten
  • angemeldete User können in einer Chronik einsehen welcher User, wann welche Werte geändert haben und die Usernamen des jeweiligen Verfassers (auch von Kommentaren) sehen und diese direkt anschreiben (s. 07. Revisionskonzept)
  • Können Einträge oder Kommentare melden, die gegen Nutzungs- oder Datenschutzbestimmungen verstoßen (automatische Weiterleitung der Meldung an alle Redakteure, automatisch wird ein Ticken in JIRA erstellt (wir schlagen die Nutzung von JIRA als Ticketsystem für die Redaktion in 1. Version vor))
  • dürfen in Version 1 zu vorhandenen OSM-Objekten Werte manuell in unsere Datenbank eintragen (s. manueller Karteneintrag / manuelle Bearbeitung von Einträgen)
  • dürfen perspektivisch:

      • Dürfen bearbeitungsrechte für eigene angelegte Datenpunkte oder eigene importierte Datensätze einschränken, wenn sie den Richtlinien entsprechen 
      • Dürfen Datensätze importieren (manuell oder per Schnittstelle)
      • Dürfen neue Kategorien und Dimensionen vorschlagen (Vorschläge werden an Redakteur weitergeleitet und müssen von diesem bestätigt werden) 
      • Haben die Möglichkeit gesperrte Datensätze zu melden, wenn diese gegen die Richtlinien oder den ethischen Rahmen des Portals verstoßen

Redakteure:

Redakteure sind User, die zu Redakteuren "aufsteigen" (Redakteur-Status muss von Administratoren vergeben werden und auch wieder entzogen werden können, kann in Version 1 getestet werden - in dieser können Redakteure ggf. auch wir sein, später dann User, die Redakteure werden):

    • Dürfen alles, was angemeldete User dürfen
    • Haben Zugriff auf Redakteur-JIRA Tickets 
    • Dürfen die Beschränkung der Bearbeitungsrechte von Content-Daten der Kategorie (b) (siehe 08. Datensätze...) an Administrator melden/Aufhebung in Auftrag geben 
    • Dürfen Schnittstellen (Daten mit eingeschränkter Bearbeitungsberechtigung nach Kategorie (a)) an Administratoren melden, die gegen die Nutzungsbedingungen verstoßen
    • Dürfen von angemeldeten Usern gemeldete Beiträge und Kommentare bearbeiten oder löschen, wenn diese gegen Nutzungs- oder Datenschutzbestimmungen verstoßen (Die Löschung wird automatisch an Administrator gemeldet (auch hier erstmal JIRA Ticket System), dieser kann Beitrag/Kommentar dann entweder wieder freigeben oder final löschen) 


  • dürfen perspektivisch:
    • neue Kategorien und Dimensionen anlegen
    • Hierarchieebenen von Kategorien verschieben
    • Benutzer sperren und melden (automatische Weiterleitung der Meldung an alle Administratoren, automatisch wird ein Ticken in JIRA erstellt (1. Version))

Administratoren:

Administratoren sind Teil des Kern-Teams (wir). GEOP-94 - Abrufen der Vorgangsdetails... STATUS

    • Dürfen alles was Redakteure dürfen
    • Haben Zugriff auf Admin-JIRA-Ticket 
    • Dürfen von angemeldeten Usern angelegte oder von Redakteuren gemeldete Werte/Datenpunkte/Kommentare unwiderruflich löschen
    • Dürfen Bearbeitungsrechte von Content-Daten der Kategorie (b) (siehe 08. Datensätze...) ändern
    • Dürfen zusätzlich Datensätze mit eingeschränkten Bearbeitungsrechten der Kategorie (b) (siehe 08. Datensätze...) bearbeiten/löschen
    • Dürfen Schnittstellen entfernen nach Kategorie (a) (siehe 08. Datensätze...)
    • Dürfen die Rolle der Benutzerkonten ändern und Benutzerkonten unwiderruflich löschen
    • Version 1: dürfen Datensätze importieren (perspektivisch dürfen das angemeldete User bereits)
    • Dürfen Kategorien unwiderruflich löschen




Anmeldung

Ablauf Anmeldung:

Ergebnis Treffen vom 11.04.: in Version wird Ablauf 2 angelegt, eine OSM-Authentifizierung wird erst gefordert, wenn User Daten, die wir aus OSM beziehen bearbeiten möchte.

Aufgabe AP1: Nutzungsbedingungen formulieren. Im unten stehenden Ablauf muss die Annahme der Nutzungsbedingungen eingearbeitet werden. Absprache 19.4.: Wird als Teil des Datenmanagementkonzepts nach Übergabe des Feinkonzeptes formuliert.

Ablauf

  1. User wählt aus: Registrieren

  2. User gibt folgende Daten an:
    Pflicht:

    • Benutzername, 
    • Passwort, (Anzeige wie sicher das Passwort ist)
    • Mailadresse
    • Zustimmung zu Nutzungsbedingungen
    Optional: 
    • perspektivisch: Foto-Upload
    • Kurzbeschreibung (Freitext)
    • Organisationszugehörigkeit
    • Interessen (Autosuggestion Schlagworte aus der Datenbank)
    • In welcher Region bin ich aktiv?: Auswahlebene: Bundesland, Stadt, Stadtteil, Quartier (Mehrfachauswahl möglich)


perspektivisch:

    • besonderes Interesse an einzelnen BLI-Dimensionen (Auswahl)
    • besonderes Interesse an Themen (Schlagworte)
    • Mitglied bei Organisation (Matching mit OSM-ID)
    • OSM-Authentifizierung

5. Emailadresse wird verifiziert

  • Solange das User-Konto nicht über OAuth mit OSM verknüpft ist, können Einträge aus der OSM-Datenbank nicht bearbeitet werden.

Perspektivisch:

  • Sobald ein User etwas eintragen möchte, dass zu der OSM-Datenbank gehört, wird OAuth abgefragt.
  • Ticketsystem für Redakteure ins GeoPortal integrieren
  • Perspektivischer Zweck des Aktionsradius bei Userprofilen:
    • Aufrufe und gezielte Informationen an Aktive in einer bestimmten Region 
    • Analysemöglichkeiten

  • Userdaten Perspektivisch: 

    • Foto-Upload
    • Organisationszugehörigkeit (wird erst relevant, wenn es Organisationsprofile gibt)
  • Organisationen (Organisationsprofile, die von einer Gruppe User im Portal "gegründet" werden)
        • In erster Version als Wert zu Organisationseinträgen eintragbar  
        • Auswahl: 
          Genauso wie bei Usern

    ________________________________________________________________



        • Perspektivischer Zweck (wenn es Organisationsprofile gibt): 
          • Aktionsradius der Organisation im jeweiligen Tätigkeitsbereich für Analysen erheben (z.B.: wie viele Organisationen arbeiten im Schnitt in Region X mit einem Aktionsradius Y?)
          • Regionaler Bezug von Organisationen soll zu Daten im Portal referenzierter sein 
          • Kooperationsvorschläge machen, etwa: Dies ist dein Wirkbereich, mit diesen und jenen Institutionen aus deinem Wirkbereich bist du bisher nicht verbunden, aber Aufgrund der BLI-Dimensionen könntet Ihr interessant füreinander sein
            Userdaten Perspektivisch: