Museum Registrar App Backend Vorlage
MuseumObjekt Standortkontrolle und Registrar-Workflows
Ein produktionsbereites Museum Registrar Backend auf Back4app mit MuseumObjektverfolgung, Sammlungsbesitz, Standortaktualisierungen, Leihvertrags-Workflows, Abtrittsprotokollverlauf und Aktivitätsprotokollprüfung. Enthält ER-Diagramm, Datenwörterbuch, JSON-Schema, API-Spielplatz und einen AI Agent Prompt für eine schnelle Einrichtung.
Wichtige Erkenntnisse für Registrar
Diese Vorlage bietet Ihnen ein Backend für den Museum-Registrar für MuseumObject-Datensätze, Standortaktualisierungen, LoanAgreement-Workflows, DeaccessionLog-Einträge und ActivityLog-Historie, damit die Sammlungs-Teams aus einer gemeinsamen Quelle der Wahrheit arbeiten können.
- Kontrolle des MuseumObject-Standorts — Modellieren Sie jedes MuseumObject mit currentLocation, status, collection, conditionSummary und provenanceNote, damit die Registrar die Akquisition vom Ausstellungsraum zum Lager verfolgen können.
- LoanAgreement-Workflow — Verfolgen Sie ausgehende und eingehende Darlehen mit LoanAgreement-Status, loanNumber, borrowingInstitution, startDate, dueDate und signedBy-Mitarbeitern.
- Verantwortlichkeit im DeaccessionLog — Dokumentieren Sie Deaccession-Entscheidungen, Genehmigungsschritte und finalDisposition-Notizen in DeaccessionLog-Einträgen, die mit jedem MuseumObject verknüpft sind.
- Registrar-freundliche Berechtigungen — Verwenden Sie ACL- und CLP-Regeln, damit Registrar, Kuratoren, Sammlungsmanager und Konservatoren nur auf die Klassen zugreifen können, denen sie zugewiesen sind.
- Einheitliche API für Sammlungsoperationen — Bedienen Sie Web-, Mobile- und Admin-Tools über eine REST- und GraphQL-Schicht für MuseumObject, Location, Collection, LoanAgreement, DeaccessionLog und ActivityLog.
Was ist die Museum Registrar App-Vorlage?
Fristen im Museum Registrar sind selten optional; eine strukturierte Datenspeicherebene verwandelt Daten in Benachrichtigungen statt in Überraschungen. Der Schwung hängt von einem genauen Zustand ab. Mit Collection, Location, MuseumObject, LoanAgreement und DeaccessionLog auf Back4app können die Teams des Museum Registrars die Trennung der Pflichten durchsetzen und gleichzeitig am selben Fallregister zusammenarbeiten. Das Schema umfasst User (Benutzername, E-Mail, Passwort, Rolle, Vollname), Collection (Zugangsnummer, Titel, Abteilung, Hauptkurator), Location (Code, Name, Typ, istSicher), MuseumObject (Zugangsnummer, Objekttitel, Objektart, Sammlung, aktueller Standort, Status), LoanAgreement (Leihnummer, MuseumObject, Leihart, entleihende Institution, Startdatum, Fälligkeitsdatum, unterschrieben von, Vertragsstatus), DeaccessionLog (Deaccessionsnummer, MuseumObject, Entscheidungsdatum, Grund, genehmigt von, endgültige Verfügung, Aufzeichnungsstatus) und ActivityLog (Darsteller, MuseumObject, Aktionstyp, AktionBei) mit integrierten Authentifizierungs- und Aufbewahrungs-Workflows. Verbinden Sie Ihr bevorzugtes Frontend und versenden Sie schneller.
Am besten für:
Wie dieses Museum Registrar-Backend organisiert ist
Spitzenwochen legen die Schulden des Museumsregistrars offen: die Abkürzungen, die im Januar in Ordnung schienen, werden zum Grund, warum Sie die Verpflichtungen im Februar nicht einhalten können.
Verwenden Sie Collection, Location und MuseumObject als Checkliste für den MVP-Bereich: Wenn es nicht modelliert ist, wird es ein Tabellenkalkulations-Workaround.
Funktionen für Museumsregistrare
Jede Technologiekarte in diesem Hub verwendet dasselbe Backend-Schema des Museumsregistrars mit User, Collection, Location, MuseumObject, LoanAgreement, DeaccessionLog und ActivityLog.
MuseumObject-Verwaltung
MuseumObject speichert accessionNumber, objectTitle, objectType, status, collection und currentLocation.
Standortverfolgung
Der Standort erfasst Code, Name, Typ und istSicher.
Darlehensvertrag Workflow
Darlehensvertrag verknüpft museumObject, loanNumber, loanType, borrowingInstitution, dueDate und agreementStatus.
Abgabeverlauf Verfolgung
Abgabeverlauf zeichnet deaccessionNumber, decisionDate, reason, finalDisposition und recordStatus auf.
Warum die Backend-App für Ihren Museumsregistrar mit Back4app erstellen?
Back4app bietet Registraren, Kuratoren und Sammlungsmanagern die Klassen, die sie benötigen, damit das Team sich auf Accession-Nummern, aktuelleStandorte und Bewegungsgeschichte anstelle von Infrastruktur konzentrieren kann.
- •MuseumObject und Location bleiben verbunden: MuseumObject- und Location-Pointer halten aktuellenStandort, Status und Sammlungsbesitz einfach abfragbar.
- •LoanAgreement-Daten bleiben überprüfbar: LoanAgreement speichert loanNumber, loanType, borrowingInstitution, startDate, dueDate, agreementStatus und signedBy für ausgehende und eingehende Objekte.
- •DeaccessionLog-Einträge sind von Anfang an strukturiert: DeaccessionLog erfasst deaccessionNumber, decisionDate, reason, approvedBy, finalDisposition und recordStatus für jeden Fall der Objektentfernung.
Erstellen Sie das Registrar-Backend einmal, und verwenden Sie dann dasselbe Schema in jedem Sammlungsworkflow und -client.
Vorteile für Registrare
Ein Museum-Backend, das den Sammlungsteams hilft, Bewegung, Darlehen und Abgaben in Ordnung zu halten.
Schnellere Objektsuchen
Beginnen Sie mit MuseumObject und Location, anstatt manuell Zugangstabelle und Lagerverfolgung Tabellen zu erstellen.
Sauberere Leihverwaltung
Verwenden Sie die Felder des LoanAgreement wie agreementStatus, dueDate, borrowingInstitution und signedBy, um ausgehende und eingehende Leihgaben sichtbar zu halten.
Nachvollziehbare Abgabehistorie
Speichern Sie Entscheidungen zur Deaccession in DeaccessionLog mit decisionDate, reason, finalDisposition und approvedBy für eine spätere Überprüfung.
Berechtigungsgrenzen für Mitarbeiterrollen
Wenden Sie ACL- und CLP-Regeln an, sodass Registratoren MuseumObject-Datensätze bearbeiten können, während breitere Mitarbeiter nur genehmigte Objektstandorte lesen.
Durchsuchbare Sammlungsoperationen
Fragen Sie MuseumObject-, Location-, LoanAgreement-, DeaccessionLog- und ActivityLog-Einträge ab, ohne das Schema jede Saison zurückzusetzen.
KI-unterstütztes Gerüst
Generieren Sie ein Museumsregistrar-Backend und Starter-Integrationen aus einem strukturierten Prompt.
Bereit, Ihre Museumsregistrar-App zu starten?
Lassen Sie den Back4app KI-Agenten Ihr Registrar-Backend gerüstet und die Workflows MuseumObject, LoanAgreement, DeaccessionLog und ActivityLog aus einem Prompt generieren.
Kostenlos starten — 50 KI-Agenten-Prompts/Monat, keine Kreditkarte erforderlich
Museums-Technologiestack
Alles enthalten in dieser Backend-Vorlage für Museum-Registrar.
ER-Diagramm für das Museum
Entitätsbeziehungsmodell für das Museum Registrar Backend-Schema.
Schema, das Benutzer, Sammlungen, Standorte, Museumobjekte, Leihverträge, Abgabeprotokolle und Aktivitätsprotokolle abdeckt.
Diagrammquelle ansehen
erDiagram
User ||--o{ Collection : "primaryCurator"
User ||--o{ LoanAgreement : "signedBy"
User ||--o{ DeaccessionLog : "approvedBy"
User ||--o{ ActivityLog : "actor"
Collection ||--o{ MuseumObject : "collection"
Location ||--o{ MuseumObject : "currentLocation"
MuseumObject ||--o{ LoanAgreement : "museumObject"
MuseumObject ||--o{ DeaccessionLog : "museumObject"
MuseumObject ||--o{ ActivityLog : "museumObject"
User {
String objectId PK
String username
String email
String password
String role
String fullName
Date createdAt
Date updatedAt
}
Collection {
String objectId PK
String accessionNumber
String title
String department
String primaryCuratorId FK
Date createdAt
Date updatedAt
}
Location {
String objectId PK
String code
String name
String type
Boolean isSecure
Date createdAt
Date updatedAt
}
MuseumObject {
String objectId PK
String accessionNumber
String objectTitle
String objectType
String collectionId FK
String currentLocationId FK
String status
String conditionSummary
String provenanceNote
Date createdAt
Date updatedAt
}
LoanAgreement {
String objectId PK
String loanNumber
String museumObjectId FK
String loanType
String borrowingInstitution
Date startDate
Date dueDate
String signedById FK
String agreementStatus
Date createdAt
Date updatedAt
}
DeaccessionLog {
String objectId PK
String deaccessionNumber
String museumObjectId FK
Date decisionDate
String reason
String approvedById FK
String finalDisposition
String recordStatus
Date createdAt
Date updatedAt
}
ActivityLog {
String objectId PK
String actorId FK
String museumObjectId FK
String actionType
String notes
Date actionAt
Date createdAt
Date updatedAt
}
Registrar-Integrationsfluss
Typischer Ablauf zur Laufzeit für Authentifizierung, MuseumObject-Abfragen, Standortaktualisierungen, LoanAgreement-Erstellung, DeaccessionLog-Aufzeichnungen und ActivityLog-Updates.
Diagrammquelle ansehen
sequenceDiagram
participant User
participant App as Museum Registrar App
participant Back4app as Back4app Cloud
User->>App: Sign in as registrar, curator, or collections manager
App->>Back4app: POST /login
Back4app-->>App: Session token
User->>App: Open object location board
App->>Back4app: GET /classes/MuseumObject?include=collection,currentLocation&order=accessionNumber
Back4app-->>App: MuseumObject list with Location and Collection pointers
User->>App: Record a transfer to storage or gallery
App->>Back4app: PUT /classes/MuseumObject/{objectId}
Back4app-->>App: Updated currentLocation and status
User->>App: Create a loan agreement or deaccession log
App->>Back4app: POST /classes/LoanAgreement or /classes/DeaccessionLog
Back4app-->>App: Agreement or log saved
App->>Back4app: Subscribe to ActivityLog updates
Back4app-->>App: Live updates for object movements and record changesMuseumsfeldführer
Vollständige feldbezogene Referenz für jede Klasse im Schema des Museumsregistrars.
| Feld | Typ | Beschreibung | Erforderlich |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | Auto |
| username | String | User login name | |
| String | User email address | ||
| password | String | Hashed password (write-only) | |
| role | String | Role of the user (e.g., registrar, curator, collections-manager, conservator, read-only-staff) | |
| fullName | String | Display name for staff and stakeholders | |
| createdAt | Date | Auto-generated creation timestamp | Auto |
| updatedAt | Date | Auto-generated last-update timestamp | Auto |
8 Felder in User
Registrar-Sicherheit und -Berechtigungen
Wie die ACL- und CLP-Strategie die MuseumObject-Datensätze, Leihunterlagen und Abgabeprotokolle schützt.
Rollenbasierter Registrar-Zugriff
Registrar können MuseumObject-, Standort-, LoanAgreement- und DeaccessionLog-Einträge erstellen und bearbeiten; andere Mitarbeiter haben, wo angemessen, nur Lesezugriff.
Leih- und Abgabekontrolle
Schreiben Sie den Zugriff auf LoanAgreement und DeaccessionLog ein, damit Genehmigungen bei autorisierten Sammlungsmitarbeitern bleiben.
Integrität der Objektvergangenheit
Verwenden Sie Cloud Code, um Aktualisierungen des aktuellenStandorts zu validieren und das Aktivitätsprotokoll vor dem Speichern von Bewegungsänderungen anzufügen.
JSON-Schema
Rohe JSON-Schema-Definition bereit zum Kopieren in Back4app oder zur Verwendung als Implementierungsreferenz.
{
"classes": [
{
"className": "User",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"username": {
"type": "String",
"required": true
},
"email": {
"type": "String",
"required": true
},
"password": {
"type": "String",
"required": true
},
"role": {
"type": "String",
"required": true
},
"fullName": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Collection",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"accessionNumber": {
"type": "String",
"required": true
},
"title": {
"type": "String",
"required": true
},
"department": {
"type": "String",
"required": true
},
"primaryCurator": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Location",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"code": {
"type": "String",
"required": true
},
"name": {
"type": "String",
"required": true
},
"type": {
"type": "String",
"required": true
},
"isSecure": {
"type": "Boolean",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "MuseumObject",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"accessionNumber": {
"type": "String",
"required": true
},
"objectTitle": {
"type": "String",
"required": true
},
"objectType": {
"type": "String",
"required": true
},
"collection": {
"type": "Pointer",
"required": true,
"targetClass": "Collection"
},
"currentLocation": {
"type": "Pointer",
"required": true,
"targetClass": "Location"
},
"status": {
"type": "String",
"required": true
},
"conditionSummary": {
"type": "String",
"required": false
},
"provenanceNote": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "LoanAgreement",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"loanNumber": {
"type": "String",
"required": true
},
"museumObject": {
"type": "Pointer",
"required": true,
"targetClass": "MuseumObject"
},
"loanType": {
"type": "String",
"required": true
},
"borrowingInstitution": {
"type": "String",
"required": true
},
"startDate": {
"type": "Date",
"required": true
},
"dueDate": {
"type": "Date",
"required": true
},
"signedBy": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"agreementStatus": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "DeaccessionLog",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"deaccessionNumber": {
"type": "String",
"required": true
},
"museumObject": {
"type": "Pointer",
"required": true,
"targetClass": "MuseumObject"
},
"decisionDate": {
"type": "Date",
"required": true
},
"reason": {
"type": "String",
"required": true
},
"approvedBy": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"finalDisposition": {
"type": "String",
"required": true
},
"recordStatus": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "ActivityLog",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"actor": {
"type": "Pointer",
"required": true,
"targetClass": "User"
},
"museumObject": {
"type": "Pointer",
"required": true,
"targetClass": "MuseumObject"
},
"actionType": {
"type": "String",
"required": true
},
"notes": {
"type": "String",
"required": false
},
"actionAt": {
"type": "Date",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
}
]
}Mit AI-Agenten erstellen
Verwenden Sie den Back4app AI-Agenten, um eine echte Museumsregistrierungs-App aus dieser Vorlage zu generieren, einschließlich Frontend, Backend, Authentifizierung sowie Objekten, Darlehen und Außerkraftsetzungen.
Erstellen Sie ein Backend für die Museum Registrar App auf Back4app mit diesem genauen Schema und Verhalten. Schema: 1. Benutzer (verwenden Sie Back4app integriert): Benutzername, E-Mail, Passwort, Rolle, vollständiger Name; objectId, createdAt, updatedAt (System). 2. Sammlung: accessionNumber (String, erforderlich), Titel (String, erforderlich), Abteilung (String, erforderlich), Hauptkurator (Pointer zu Benutzer, erforderlich); objectId, createdAt, updatedAt (System). 3. Standort: code (String, erforderlich), name (String, erforderlich), type (String, erforderlich), isSecure (Boolean, erforderlich); objectId, createdAt, updatedAt (System). 4. MuseumObjekt: accessionNumber (String, erforderlich), objectTitle (String, erforderlich), objectType (String, erforderlich), Sammlung (Pointer zu Sammlung, erforderlich), currentLocation (Pointer zu Standort, erforderlich), status (String, erforderlich), conditionSummary (String, optional), provenanceNote (String, optional); objectId, createdAt, updatedAt (System). 5. Leihvereinbarung: loanNumber (String, erforderlich), museumObject (Pointer zu MuseumObjekt, erforderlich), loanType (String, erforderlich), borrowingInstitution (String, erforderlich), startDate (Datum, erforderlich), dueDate (Datum, erforderlich), signedBy (Pointer zu Benutzer, erforderlich), agreementStatus (String, erforderlich); objectId, createdAt, updatedAt (System). 6. Abgabeprotokoll: deaccessionNumber (String, erforderlich), museumObject (Pointer zu MuseumObjekt, erforderlich), decisionDate (Datum, erforderlich), reason (String, erforderlich), approvedBy (Pointer zu Benutzer, erforderlich), finalDisposition (String, erforderlich), recordStatus (String, erforderlich); objectId, createdAt, updatedAt (System). 7. Aktivitätsprotokoll: actor (Pointer zu Benutzer, erforderlich), museumObject (Pointer zu MuseumObjekt, erforderlich), actionType (String, erforderlich), notes (String, optional), actionAt (Datum, erforderlich); objectId, createdAt, updatedAt (System). Sicherheit: - Registrar-, Kurator- und Sammlungsmanager-Rollen können MuseumObjekt-, Standort-, Leihvereinbarungs- und Abgabeprotokolle gemäß ihrer Verantwortung erstellen und bearbeiten. - Beschränken Sie den Schreibzugriff auf Sammlungs- und Objektakten auf autorisierte Mitarbeiter. - Halten Sie Leih- und Abgabeeinträge prüfbar; bewahren Sie die Aktivitätsprotokollhistorie. Auth: - Registrierung, Anmeldung, Abmeldung. Verhalten: - Verfolgen Sie Objektstandorte, verwalten Sie Leihvereinbarungen und erfassen Sie Abgabeprotokolle. - Zeigen Sie Sammlungen nach Abteilung und Objekte nach aktuellem Standort und Status an. - Speichern Sie Aktivitätsnotizen, wenn ein MuseumObjekt bewegt wird, ein Darlehen unterzeichnet wird oder eine Abgabe genehmigt wird. Lieferung: - Back4app App mit Schema, CLPs, ACLs und einer Schnittstelle für Registrar, Kuratoren, Sammlungsmanager und Konservatoren zur Verwaltung von Objektbewegungen, Darlehensunterlagen und Abgabe-Workflows.
Drücken Sie die Schaltfläche unten, um den Agenten mit dieser Vorlage vorab ausgefülltem Prompt zu öffnen.
Dies ist die Basisaufforderung ohne einen Technologiesuffix. Sie können den generierten Frontend-Stack anschließend anpassen.
API-Sandbox
Testen Sie REST und GraphQL Endpunkte gegen das Museum Registrar-Schema. Antworten verwenden Mock-Daten und erfordern kein Back4app Konto.
Verwendet dasselbe Schema wie diese Vorlage.
Wählen Sie Ihre Technologie
Erweitern Sie jede Karte, um zu sehen, wie Sie Collection, Location und MuseumObject mit Ihrem gewählten Stack integrieren können.
Flutter Museum Registrar Backend
React Museum Registrar Backend
React Native Museum Registrar Backend
Next.js Museum Registrar Backend
JavaScript Museum Registrar Backend
Android Museum Registrar Backend
iOS Museum Registrar Backend
Vue Museum Registrar Backend
Angular Museum Registrar Backend
GraphQL Museum Registrar Backend
REST API Museum Registrar Backend
PHP Museum Registrar Backend
.NET Museum Registrar Backend
Was Sie mit jeder Technologie erhalten
Jeder Stack verwendet das gleiche Backend-Schema und die API-Verträge des Museumsregistrars.
Einheitliche Museumsdatenstruktur
Verwalten Sie MuseumObject-Datensätze, Standorteinträge, LoanAgreement-Dateien und DeaccessionLog-Notizen mit einem Schema.
Objektstandortverfolgung für Sammlungsteams
Halten Sie den aktuellen Standort und die Aktivitätshistorie für Registrare und Kuratoren lesbar.
Arbeitsabläufe für Kreditvereinbarungen für Museen
Speichern Sie borrowingInstitution, dueDate, agreementStatus und signedBy in einem strukturierten Ablauf.
Abgabe-Dokumentation für Museen
Aufzeichnen von recordStatus, decisionDate und Grund für Überprüfung und Audit.
REST/GraphQL APIs für Museums-Apps
Verbinden Sie Web-, Mobile- und interne Tools mit flexiblen APIs.
Erweiterbare Architektur für Sammlungsoperationen
Fügen Sie Felder oder Klassen hinzu, während sich die Akquisitionen und Ausstellungen entwickeln.
Vergleich der Museum-Registrar-Stacks
Vergleichen Sie die Einrichtungsgeschwindigkeit, den SDK-Stil und die KI-Unterstützung aller unterstützten Technologien.
| Framework | Einrichtungszeit | Vorteil für den Museumsregistrator | SDK-Typ | KI-Unterstützung |
|---|---|---|---|---|
| Ungefähr 5 Minuten | Einzelne Codebasis für mobile und Web-Tools für Registrare. | Typisiertes SDK | Vollständig | |
| Unter 5 Minuten | Schnelles Web-Dashboard für Objektverfolgung. | Typisierte SDK | Vollständig | |
| ~3–7 Min | Plattformübergreifende mobile App für das Sammlungsteam. | Typisierte SDK | Vollständig | |
| Schnelle (5 Min) Einrichtung | Serverseitig gerenderter Registrierungsportal für Mitarbeiter. | Typisierte SDK | Vollständig | |
| ~3–5 min | Leichte Webintegration für Registrierungswerkzeuge. | Typed SDK | Vollständig | |
| Ungefähr 5 min | Native Android-App zur Verfolgung von Galerien und Speicher. | Typed SDK | Vollständig | |
| Unter 5 Minuten | Native iOS-App für Museumspersonal. | Typed SDK | Vollständig | |
| ~3–7 min | Reactive Web-Benutzeroberfläche für Sammlungsoperationen. | Getippte SDK | Vollständig | |
| Schnelle (5 Min) Einrichtung | Enterprise-Webanwendung für Registrierungsarbeitsabläufe. | Getippte SDK | Vollständig | |
| Unter 2 Min | Flexibles GraphQL API für Objekt- und Darlehensansichten. | GraphQL API | Vollständig | |
| Schnelle (2 Min) Einrichtung | REST API-Integration für Registrarsysteme. | REST API | Vollständig | |
| ~3 Min | Server-seitiges PHP-Backend für Museumstools. | REST API | Vollständig | |
| ~3–7 Min | .NET-Backend für das Sammlungsmanagement. | Typisierte SDK | Vollständig |
Die Einrichtungszeit spiegelt die erwartete Dauer von der Projektinitialisierung bis zur ersten MuseumObject- oder LoanAgreement-Abfrage mit diesem Schema wider.
Fragen des Museum-Registrars
Häufige Fragen zum Aufbau eines Backend für Museum-Registrare mit dieser Vorlage.
Bereit, Ihre Museums-Registrar-App zu erstellen?
Starten Sie Ihr Museumsregistrierungsprojekt in wenigen Minuten. Keine Kreditkarte erforderlich.