FabAccess - Versionen, Changelog, Roadmap

Roadmap

Server

LDAP-Integration - bis 12/2024
Single Sign On (SSO) per Keycloak / OpenID Connect - bis 12/2024
noch mehr komplexe Zustände: z.B. "Schalten nur, wenn auch die Kühlung oder Absaugung angeschalten ist!" oder "Schalte aus, wenn der letzte gegangen ist"
Föderation: Werkstätten haben eine technische Bais für Verträge/Abrechnungen, die das Leben einfacher für jeden machen und Plastikkarten sparen - Stufe 3 implementieren
Measurements implementieren
welche Permissions and Roles sind mit der aktuellsten Version möglich?
- https://docs.fab-access.org/books/fabaccess-setup/page/benutzerrollen-und-berechtigungen-rbac
sind Terminals möglich?
- https://docs.fab-access.org/books/fabaccess-setup/page/terminals
Projekte implementieren
Ausleihfunktion implementieren

Client

- Client Web App (Borepin-Nachfolger)
  - Bedarf einer neuen App, die plattformübergreifend ist
  - außerdem: Xamarin-Support wurde am 01.05.2024 durch Microsoft beendet
- Client Borepin
  - Switch auf AvaloniaUI zum Adressieren von GTK (Gnome Toolkit) / Linux

Community Feature Request:Requests

SRV Record Unterstützung für Clients

Maschinen nach einer Inaktivitätszeit X automatisch ausschalten (Aktivitätsmessung, Verbrauchsmessung?)
- BFFH soll über sog. "Sensoren" Informationen über die Welt rausfinden. Das werden so wie Aktoren & Initiatoren modulare Stücke Code oder sogar externe Skripte sein, die relativ unabhängig vom restlichen Code sind. Gemanagte Ressourcen (aka "Maschinen") können dann via der Config "Module" definieren, die ihr Verhalten verändern können. Eines dieser Module nimmt Daten aus so einem Sensor und gibt eine Ressource wieder frei wenn sie augenscheinlich nicht mehr verwendet wird.
- Implementierung der Aktivitätsmessung ist noch nicht ganz klar, aber der Modularität halber wird es sehr wahrscheinlich so aussehen, dass genau das nur im Sensor passiert und der Sensor nur mehr einen Output von "wird gerade verwendet" oder "wird nicht verwendet" hat. Wie genau der Sensor das errät, ist dann das nächste Problem, aber jetzt im Bezug auf das vorhandene Skript hieße das dann mehr oder weniger nur, dass das anstatt von direkt auf den MQTT-Bus zu schreiben in BFFH reinschreibt.

App und/oder Server: Pet Names / nutzerfreundliche Namen: sich keine Nick Names merken müssen ((z.B. in einer zweiten Zeile unter dem Username). Wenn man z.B. Mitgliedschaftsnummern als Login verwendet, dann ist die User-Liste in der App nicht wirklich gut nutzbar, weil man zusätzlich eine Liste mit den Account-Zuordnungen benötigt.

Meta-Daten für Maschinen und Nutzer ergänzen, z.B. Adressen, Mitgliedsnummer, Avatar, Beschreibungen, etc. - könnten dann z.B. in Abrechnungssystem gegeben werden, im Audit Log auftauchen oder einfach nur in der App bessere Details anzeigen

Zugangsdaten für Mitglieder als QR-Code einscannen. Hintergrund: Zur Identifikation mit civiCRM verwenden wir eine vierstellige UserID, die sich keiner merkt. Um das "Problemchen" zu umgehen wäre es nett die initialen Anmeldedaten innerhalb eines QR-Codes / Links einscannen zu können

Release History

Bei den folgend genannten Versionen wird primär von der API-Version gesprochen! Die Versionen des Servers und des Referenz-Clients können sich unterschieden. Clients in den App Stores müssen der Server-Version entsprechen, bis die Version 1.0 erreicht ist!

☑️ 0.4 Beta (aktuell)
☑️ 0.3 öffentliche Alpha "Spigots of Berlin" (04/2022)
☑️ 0.2 Joris-Alpha (01/2022)
☑️ 0.1 historische Alpha-Version

Siehe auch Stichwort release.

Alle Releases von Borepin und Diflouroborane (BFFH) finden sich in GitLab:

Release- und Versionierungsschema

Wie werden die FabAccess Repositories versioniert? Welchen Regeln folgt es?

Das Versionsschema lautet A.B.C. Wofür die 3 Stellen A, B und C stehen, ist leider nirgends erläutert.

Folgende Release-Stages gibt es:

Internal - nur für interner Tests
Beta - für externe Tester
Production - für alle Nutzer