Admin-Panel

Jede veröffentlichte Proyecta-App enthält ein Admin-Panel – ein privates, anmeldegeschütztes Back-Office, in dem du deine Inhalte und Formular-Einsendungen verwalten kannst, ohne Code zu berühren.

Die öffentliche Seite deiner App ist individuell und markenspezifisch. Dahinter braucht jede App dasselbe unspektakuläre, aber unverzichtbare Back-Office: einen Ort, um Inhalte zu bearbeiten, Leads zu prüfen und den laufenden Betrieb zu steuern. Proyecta baut das für dich aus schema-gesteuerten, template-eigenen Komponenten – damit bleibt es über alle Apps hinweg konsistent und korrekt, und du wartest nie darauf, dass die KI einen CRUD-Screen von Hand zusammenbastelt.

Was du verwalten kannst

Bereich	Was es tut	Status
Inhalte	Einträge in deinen Collections erstellen, bearbeiten, veröffentlichen und archivieren	Verfügbar
Formular-Einsendungen	Einsendungen aus deinen Formularen prüfen, als gelesen markieren und archivieren	Verfügbar
Commerce-Bestellungen	Bestellungen aus deinem Storefront prüfen und abwickeln	Verfügbar
Mitglieder / Nutzer	Die Personen verwalten, die sich in deiner App angemeldet haben, und ihre Rollen	Verfügbar

Welche Bereiche du siehst, hängt davon ab, was deine App tut – das Panel liest die Live-Form deiner App aus und rendert nur, was zutrifft. Eine App ohne Storefront hat keinen Bestellungen-Bereich.

Wer Zugang hat

Das Admin-Panel ist RBAC-gesichert. Ein Besucher muss mit einem Admin-Konto angemeldet sein, um es zu sehen – jede Admin-Aktion wird auf dem Server durchgesetzt, nicht nur in der UI ausgeblendet.

Admin-Rechte werden an die E-Mail-Adresse vergeben, die du bei der Erstellung der App festlegst, abgeglichen mit der verifizierten Adresse des Identity-Providers. Sie gehen nicht an die Person, die sich als Erste anmeldet – in einer normalen App melden sich alle anderen als gewöhnliche Nutzer an, auch die Person, die die App zuerst besucht. Wie die Anmeldung funktioniert und wie Rollen vergeben werden, erfährst du unter Users & Auth.

Die Bausteine

Das Panel wird aus template-eigenen Komponenten zusammengesetzt. Du schreibst diese nicht – sie sind Teil jeder App –, aber es hilft, die wichtigsten zu kennen:

Komponente	Was sie dir bietet
`CollectionManager`	Ein vollständiger Admin-Screen für eine Collection: eine durchsuchbare, sortierbare Liste plus ein automatisch generiertes Erstellen-/Bearbeiten-Formular. Einmal pro Collection.
`SubmissionsInbox`	Der Posteingang für Formulare: Tabs für Neu / Gelesen / Archiviert, ein Badge für ungelesene Einträge und eine Detailansicht pro Einsendung.
`AdminShell`	Der Rahmen um alles – eine ein-/ausklappbare Seitenleiste und eine obere Leiste, die alle Bereiche miteinander verbindet.

CollectionManager: automatisches CRUD aus deinem Schema

CollectionManager liest das Schema einer Collection und baut die gesamte Bearbeitungsoberfläche mit nahezu null handgeschriebenem Code auf:

Listet deine Einträge in einer Tabelle mit Status-Badge, Suchfunktion und einem New-Button.
Generiert das Formular automatisch aus dem Typ jedes Feldes – Textfelder werden zu Inputs, langer Text wird zu einer Textarea, Zahlen werden zu Number-Inputs, Ein-/Aus-Werte werden zu Switches, Auswahlfelder werden zu Dropdowns, Datumsfelder zu Date-Pickern, Referenzen zu einem Picker über die verknüpfte Collection, und Bildfelder erhalten einen Upload-Button (mit Media-Library-Picker und Fallback für eingefügte URLs).
Speichert zunächst als Entwurf – das Veröffentlichen ist eine explizite, separate Aktion, damit nichts versehentlich live geht. Du kannst einen Eintrag auch unpublishen oder archivieren (Archivieren ist ein Soft Delete – der Eintrag verschwindet aus der App und dem Panel, wird aber nicht gelöscht).
Verarbeitet auch einmalige Inhalte: Singleton-Collections (wie deine Geschäftsdaten) zeigen das Formular direkt an, ohne Liste.

Die Bearbeitung ist wirklich ohne Code: Du (oder jede Person, der du Admin-Rechte gibst) änderst Texte, Preise, Fotos und Öffnungszeiten im Panel, klickst auf Publish, und die Live-App aktualisiert sich.

Hinweis: Commerce-Produkte werden mit den Commerce-Tools verwaltet, nicht in einem CollectionManager – auch wenn der Katalog Inhalte sind. Siehe Commerce.

Wie das Admin-Panel aufgebaut wird

Du musst nicht danach fragen, und die KI baut es nicht von Hand. Das Panel ist ein selbstkonfigurierendes „stehendes Admin-Panel“: ein festes /admin, das im Template jeder App verankert ist, dein live Content-Schema und deine Capability-Konfiguration ausliest und sich selbst rendert – ohne KI-Verkabelung. Füge später eine neue Collection hinzu, und sie erscheint automatisch, ganz ohne Rebuild.

Über Inhalte und Formular-Einsendungen hinaus erscheinen Bereiche für alles, was deine App tatsächlich tut – Bestellungen und Retouren, Buchungen und Terminplanung, Mitglieder und Rollen, eine Media Library, E-Mail und Push. Du bekommst die, die zu deiner App passen, und keine von denen, die es nicht tun.

Weil es dem Template gehört, bleibt es über alle Apps hinweg konsistent und korrekt und kann nicht abdriften oder kaputtgehen, wenn die KI deine öffentlichen Seiten bearbeitet. Wenn du später die Konsole selbst geändert haben möchtest, sag Bescheid – das ist eine explizite Änderung und nichts, was der erste Build improvisiert.

Häufige Muster

Nach dem Admin-Panel selbst musst du nie fragen – jede App bringt es mit, und neue Collections tauchen dort von allein auf. Was sich lohnt, die KI zu fragen:

"Add a 'featured' toggle to my services so I can choose what shows on the homepage." – neue Felder erscheinen automatisch im Admin-Panel.
"Make the headline and hours on my homepage editable from the admin." – verschiebt fest im Code stehende Texte in die Inhalte.
"Build me a back-office page showing this week's bookings at a glance." – eine maßgeschneiderte Seite, zusammengesetzt aus denselben Bausteinen.