FabAccess Roadmap / Ziele

• 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: wie wie weit ist Föderation mit FabAccess aktuell machbar?
  
• 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
•  

Weitere Anfragen / Community Feature 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 

• Login mit FIDO2 / Passkeys / YubiKey?
• Login mit SmartCard via ReinerSCT Card Reader?
• Internationalisierung
  • Client auf Deutsch
• Wie installiert man FabAccess betriebssicher? (Fail-Over Strategien, Backup-Strategien). Was machen, wenn der FabAccess Server down ist?
  • Zweit-Server mit Spiegelung der Datenbank?
  • High-Availability Cluster (Kubernetes?)
  • Unterbrechungsfreie Stromversorgung (USV)?
  • Funkunterbrechungen / schlechte Signalstärken (da, wo es möglich ist, ein Ethernetkabel ziehen)
• Wie/mit welchem Tool lassen sich Maschineneinweisungen sinnvoll tracken/ins System einbinden?