Freigeben & veröffentlichen
Vom Entwurf zur sichtbaren Seite: CAMPUS kennt einen klaren Freigabe-Workflow, damit nur geprüfte Inhalte live gehen. Diese Seite erklärt die Zustände, die Rollen, den konkreten Ablauf und was Sie vor dem Veröffentlichen prüfen sollten.
Warum es einen Workflow gibt
Ohne geregelte Freigabe landet jeder Entwurf sofort bei den Nutzern — mit Tippfehlern, halben Sätzen und ungeprüften Aussagen. Der Workflow trennt Arbeiten von Veröffentlichen: Sie bauen in Ruhe, jemand prüft, dann geht es live. Das schützt Qualität und Vertrauen.
Die Zustände & Übergänge
Jedes Product durchläuft Zustände; die Übergänge haben feste Namen (auch in der API):
Aus Archiviert holt der Übergang refresh ein Product zurück in die Bearbeitung. Direktes Veröffentlichen (publish/activate) ist möglich, wenn Sie das Recht dazu haben.
Wer darf was? (Reviewer)
Ob Sie selbst veröffentlichen dürfen oder nur „Freigabe anfragen" können, hängt von Ihren Rechten ab (Feld canPublish). Das Prüfen & Genehmigen übernimmt die Rolle Reviewer — ein zuschaltbares Recht (siehe Rollen & Rechte). So entsteht ein sauberes Vier-Augen-Prinzip: Editor erstellt, Reviewer gibt frei.
So geht's konkret
- Fertig stellenInhalt, Sprache(n), Kategorien/Tags und Zugriff prüfen.
- Freigabe anfragenAm Product den Status auf „Freigabe anfragen" setzen (
request_approval). - Prüfen lassenEin Reviewer sieht die Anfrage, prüft und genehmigt (
approve) — oder gibt sie mit Hinweisen zurück. - VeröffentlichenNach Freigabe wird das Product aktiv und für die Zielgruppe sichtbar.
- Später pflegenVeraltetes archivieren; zum Überarbeiten mit
refreshzurückholen.
Prüf-Checkliste vor dem Veröffentlichen
- Alle Sprachen? Titel, Lead und Inhalt je aktiver Sprache (mind. DEFAULT).
- Kategorien & Tags? Sonst wird der Inhalt schlecht gefunden.
- Zugriff korrekt? Öffentlich, Gruppe oder Restriction-Preset wie gewünscht.
- Hero-Bild & Vorschau? Der erste Eindruck zählt.
- Links & Medien? Funktionieren, richtige Assets, Rechte geklärt.
Sichtbarkeit ≠ Berechtigung. Veröffentlichen macht ein Product „live" — die tatsächliche Sichtbarkeit steuern zusätzlich die Restrictions. Prüfen Sie im Zweifel mit einem Testkonto der Zielgruppe.
Troubleshooting
Ich sehe keinen „Veröffentlichen"-Knopf, nur „Freigabe anfragen".
Dann fehlt Ihnen das canPublish-Recht. Das ist Absicht (Vier-Augen-Prinzip) — ein Reviewer/Admin gibt frei.
Veröffentlicht, aber Nutzer sehen nichts.
Fast immer eine Restriction oder eine fehlende Kategorie. Empfänger/Sichtbarkeit mit Testkonto prüfen.
Ich muss eine veröffentlichte Seite korrigieren.
Bearbeiten Sie sie im Edit-Mode; je nach Konfiguration durchläuft die Änderung erneut die Freigabe. Für größere Umbauten ggf. archivieren und mit refresh neu aufsetzen.
Verwandtes
Zum Abschluss des Kapitels: How to: perfekte Inhalte.
Approve & publish
From draft to a visible page: CAMPUS has a clear approval workflow so that only reviewed content goes live. This page explains the states, the roles, the concrete process and what you should check before publishing.
Why there is a workflow
Without a regulated approval, every draft lands with users immediately — with typos, half sentences and unreviewed statements. The workflow separates working from publishing: you build in peace, someone reviews, then it goes live. This protects quality and trust.
The states & transitions
Every product goes through states; the transitions have fixed names (also in the API):
From Archived, the refresh transition brings a product back into editing. Direct publishing (publish/activate) is possible if you have the right to do so.
Who may do what? (Reviewer)
Whether you may publish yourself or can only “request approval” depends on your rights (field canPublish). The reviewing & approving is handled by the Reviewer role — an addable right (see Roles & rights). This creates a clean four-eyes principle: the editor creates, the reviewer approves.
Step by step
- FinaliseCheck content, language(s), categories/tags and access.
- Request approvalSet the product status to “Request approval” (
request_approval). - Have it reviewedA reviewer sees the request, reviews and approves (
approve) — or returns it with notes. - PublishAfter approval the product becomes active and visible to the target group.
- Maintain laterArchive outdated content; bring it back for revision with
refresh.
Review checklist before publishing
- All languages? Title, lead and content per active language (at least DEFAULT).
- Categories & tags? Otherwise the content is hard to find.
- Access correct? Public, group or restriction preset as intended.
- Hero image & preview? The first impression counts.
- Links & media? Working, the right assets, rights clarified.
Visibility ≠ authorisation. Publishing makes a product “live” — the actual visibility is additionally controlled by the restrictions. When in doubt, check with a test account of the target group.
Troubleshooting
I don’t see a “Publish” button, only “Request approval”.
Then you lack the canPublish right. That is intentional (four-eyes principle) — a reviewer/admin approves.
Published, but users see nothing.
Almost always a restriction or a missing category. Check recipients/visibility with a test account.
I need to correct a published page.
Edit it in edit mode; depending on the configuration the change goes through approval again. For larger rebuilds, archive it if necessary and set it up anew with refresh.
Related
To close the chapter: How to: perfect content.
Valider & publier
Du brouillon à la page visible : CAMPUS dispose d'un workflow de validation clair, afin que seuls des contenus vérifiés passent en ligne. Cette page explique les états, les rôles, le déroulement concret et ce que vous devez vérifier avant la publication.
Pourquoi il existe un workflow
Sans validation encadrée, chaque brouillon atterrit immédiatement chez les utilisateurs — avec des fautes de frappe, des phrases à moitié faites et des affirmations non vérifiées. Le workflow sépare le travail de la publication : vous construisez tranquillement, quelqu'un vérifie, puis cela passe en ligne. Cela protège la qualité et la confiance.
Les états & transitions
Chaque Product traverse des états ; les transitions ont des noms fixes (aussi dans l'API) :
Depuis Archivé, la transition refresh ramène un Product en édition. La publication directe (publish/activate) est possible si vous en avez le droit.
Qui a le droit de quoi ? (Reviewer)
Que vous puissiez publier vous-même ou seulement « demander la validation » dépend de vos droits (champ canPublish). La vérification & l'approbation reviennent au rôle Reviewer — un droit activable (voir Rôles & droits). Ainsi naît un principe des quatre yeux propre : l'éditeur crée, le Reviewer valide.
Concrètement
- FinaliserVérifier le contenu, la ou les langues, les catégories/tags et l'accès.
- Demander la validationSur le Product, mettre le statut sur « Demander la validation » (
request_approval). - Faire vérifierUn Reviewer voit la demande, vérifie et approuve (
approve) — ou la retourne avec des remarques. - PublierAprès validation, le Product devient actif et visible pour le public cible.
- Entretenir plus tardArchiver ce qui est obsolète ; le ramener avec
refreshpour le retravailler.
Checklist de vérification avant la publication
- Toutes les langues ? Titre, lead et contenu pour chaque langue active (au moins DEFAULT).
- Catégories & tags ? Sinon le contenu est mal trouvé.
- Accès correct ? Public, groupe ou Restriction-Preset comme souhaité.
- Image hero & aperçu ? La première impression compte.
- Liens & médias ? Fonctionnent, bons Assets, droits clarifiés.
Visibilité ≠ autorisation. Publier rend un Product « live » — la visibilité réelle est en plus pilotée par les Restrictions. En cas de doute, vérifiez avec un compte de test du public cible.
Dépannage
Je ne vois pas de bouton « Publier », seulement « Demander la validation ».
C'est qu'il vous manque le droit canPublish. C'est intentionnel (principe des quatre yeux) — un Reviewer/admin valide.
Publié, mais les utilisateurs ne voient rien.
Presque toujours une Restriction ou une catégorie manquante. Vérifiez destinataires/visibilité avec un compte de test.
Je dois corriger une page publiée.
Modifiez-la dans l'Edit-Mode ; selon la configuration, la modification repasse par la validation. Pour de plus grandes refontes, archivez le cas échéant et repartez avec refresh.
En lien
Pour clore le chapitre : How to : des contenus parfaits.
Zatwierdzanie i publikacja
Od wersji roboczej do widocznej strony: CAMPUS ma jasny proces zatwierdzania, dzięki któremu na żywo trafiają tylko sprawdzone treści. Ta strona wyjaśnia stany, role, konkretny przebieg oraz to, co należy sprawdzić przed publikacją.
Dlaczego istnieje ten proces
Bez uregulowanego zatwierdzania każda wersja robocza od razu trafia do użytkowników — z literówkami, niedokończonymi zdaniami i niesprawdzonymi stwierdzeniami. Proces oddziela pracę od publikacji: budujesz w spokoju, ktoś sprawdza, a potem trafia to na żywo. To chroni jakość i zaufanie.
Stany i przejścia
Każdy Product przechodzi przez stany; przejścia mają stałe nazwy (także w API):
Ze stanu Zarchiwizowany przejście refresh przywraca Product do edycji. Bezpośrednia publikacja (publish/activate) jest możliwa, jeśli masz do tego uprawnienie.
Kto co może? (Reviewer)
To, czy możesz publikować samodzielnie, czy tylko „poprosić o zatwierdzenie", zależy od Twoich uprawnień (pole canPublish). Sprawdzanie i zatwierdzanie przejmuje rola Reviewer — dołączalne uprawnienie (zob. Role i uprawnienia). Tak powstaje czysta zasada dwóch par oczu: edytor tworzy, Reviewer zatwierdza.
Jak to zrobić konkretnie
- DokończenieSprawdź treść, język(i), kategorie/tagi i dostęp.
- Prośba o zatwierdzenieUstaw status Product na „Poproś o zatwierdzenie" (
request_approval). - SprawdzenieReviewer widzi prośbę, sprawdza i zatwierdza (
approve) — albo zwraca ją z uwagami. - PublikacjaPo zatwierdzeniu Product staje się aktywny i widoczny dla grupy docelowej.
- Późniejsza pielęgnacjaPrzestarzałe zarchiwizuj; do przeróbki przywróć za pomocą
refresh.
Lista kontrolna przed publikacją
- Wszystkie języki? Tytuł, lead i treść dla każdego aktywnego języka (min. DEFAULT).
- Kategorie i tagi? W przeciwnym razie treść będzie źle wyszukiwalna.
- Dostęp poprawny? Publiczny, grupa lub Restriction-Preset zgodnie z zamierzeniem.
- Obraz hero i podgląd? Liczy się pierwsze wrażenie.
- Linki i media? Działają, właściwe zasoby, prawa wyjaśnione.
Widoczność ≠ uprawnienie. Publikacja czyni Product „aktywnym" — o rzeczywistej widoczności dodatkowo decydują restrykcje. W razie wątpliwości sprawdź na koncie testowym grupy docelowej.
Rozwiązywanie problemów
Nie widzę przycisku „Publikuj", tylko „Poproś o zatwierdzenie".
Brakuje Ci wtedy uprawnienia canPublish. To celowe (zasada dwóch par oczu) — Reviewer/Admin zatwierdza.
Opublikowane, ale użytkownicy nic nie widzą.
Prawie zawsze to restrykcja albo brakująca kategoria. Sprawdź odbiorców/widoczność na koncie testowym.
Muszę poprawić opublikowaną stronę.
Edytuj ją w Edit-Mode; w zależności od konfiguracji zmiana ponownie przechodzi przez zatwierdzenie. Przy większych przebudowach ewentualnie zarchiwizuj i utwórz na nowo za pomocą refresh.
Powiązane
Na zakończenie rozdziału: How to: doskonałe treści.
Approvare e pubblicare
Dalla bozza alla pagina visibile: CAMPUS prevede un chiaro workflow di approvazione, affinché vadano online solo contenuti verificati. Questa pagina spiega gli stati, i ruoli, il processo concreto e cosa dovrebbe verificare prima di pubblicare.
Perché esiste un workflow
Senza un'approvazione regolata, ogni bozza finisce subito agli utenti — con refusi, frasi incomplete e affermazioni non verificate. Il workflow separa il lavorare dal pubblicare: Lei costruisce con calma, qualcuno verifica, poi va online. Ciò protegge la qualità e la fiducia.
Gli stati e le transizioni
Ogni Product attraversa degli stati; le transizioni hanno nomi fissi (anche nell'API):
Da Archiviato, la transizione refresh riporta un Product in lavorazione. La pubblicazione diretta (publish/activate) è possibile se ne possiede il diritto.
Chi può fare cosa? (Reviewer)
Se Lei stesso possa pubblicare o soltanto „richiedere l'approvazione" dipende dai Suoi diritti (campo canPublish). La verifica e l'approvazione spettano al ruolo Reviewer — un diritto attivabile (vedi Ruoli e diritti). Nasce così un pulito principio dei quattro occhi: l'editore crea, il Reviewer approva.
Come procedere in concreto
- FinalizzareVerificare contenuto, lingua/e, categorie/tag e accesso.
- Richiedere l'approvazioneSul Product, impostare lo stato su „Richiedi approvazione" (
request_approval). - Far verificareUn Reviewer vede la richiesta, verifica e approva (
approve) — oppure la restituisce con indicazioni. - PubblicareDopo l'approvazione, il Product diventa attivo e visibile per il gruppo target.
- Curare in seguitoArchiviare ciò che è obsoleto; per rielaborarlo, richiamarlo con
refresh.
Checklist di verifica prima della pubblicazione
- Tutte le lingue? Titolo, lead e contenuto per ciascuna lingua attiva (almeno DEFAULT).
- Categorie e tag? Altrimenti il contenuto viene trovato con difficoltà.
- Accesso corretto? Pubblico, gruppo o Restriction-Preset come desiderato.
- Hero-Image e anteprima? La prima impressione conta.
- Link e media? Funzionanti, Assets corretti, diritti chiariti.
Visibilità ≠ autorizzazione. La pubblicazione rende un Product „live" — la visibilità effettiva è regolata inoltre dalle Restrictions. Nel dubbio, verifichi con un account di test del gruppo target.
Risoluzione dei problemi
Non vedo alcun pulsante „Pubblica", solo „Richiedi approvazione".
Allora Le manca il diritto canPublish. È voluto (principio dei quattro occhi) — un Reviewer/Admin approva.
Pubblicato, ma gli utenti non vedono nulla.
Quasi sempre una Restriction o una categoria mancante. Verificare destinatari/visibilità con un account di test.
Devo correggere una pagina pubblicata.
La modifichi nell'Edit-Mode; a seconda della configurazione, la modifica ripercorre l'approvazione. Per rimaneggiamenti maggiori, eventualmente archiviare e ricostruire con refresh.
Argomenti correlati
A conclusione del capitolo: How to: contenuti perfetti.
Vrijgeven & publiceren
Van concept naar zichtbare pagina: CAMPUS kent een duidelijke vrijgave-workflow, zodat alleen gecontroleerde inhoud live gaat. Deze pagina legt de statussen, de rollen, de concrete werkwijze en wat u vóór het publiceren moet controleren uit.
Waarom er een workflow is
Zonder geregelde vrijgave belandt elk concept meteen bij de gebruikers — met typefouten, halve zinnen en ongecontroleerde uitspraken. De workflow scheidt werken van publiceren: u bouwt in alle rust, iemand controleert, dan gaat het live. Dat beschermt kwaliteit en vertrouwen.
De statussen & overgangen
Elk Product doorloopt statussen; de overgangen hebben vaste namen (ook in de API):
Vanuit Gearchiveerd haalt de overgang refresh een Product terug in bewerking. Direct publiceren (publish/activate) is mogelijk als u daar het recht toe heeft.
Wie mag wat? (Reviewer)
Of u zelf mag publiceren of alleen „vrijgave aanvragen" kunt, hangt af van uw rechten (veld canPublish). Het controleren & goedkeuren neemt de rol Reviewer over — een inschakelbaar recht (zie Rollen & rechten). Zo ontstaat een net vier-ogenprincipe: editor maakt, reviewer geeft vrij.
Zo werkt het concreet
- AfrondenInhoud, taal/talen, categorieën/tags en toegang controleren.
- Vrijgave aanvragenBij het Product de status op „vrijgave aanvragen" zetten (
request_approval). - Laten controlerenEen reviewer ziet de aanvraag, controleert en keurt goed (
approve) — of stuurt hem met opmerkingen terug. - PublicerenNa vrijgave wordt het Product actief en zichtbaar voor de doelgroep.
- Later onderhoudenVerouderd materiaal archiveren; voor herziening met
refreshterughalen.
Controlelijst vóór het publiceren
- Alle talen? Titel, lead en inhoud per actieve taal (min. DEFAULT).
- Categorieën & tags? Anders wordt de inhoud slecht gevonden.
- Toegang correct? Openbaar, groep of Restriction-Preset zoals gewenst.
- Hero-afbeelding & voorbeeld? De eerste indruk telt.
- Links & media? Werken, juiste assets, rechten geregeld.
Zichtbaarheid ≠ toestemming. Publiceren maakt een Product „live" — de daadwerkelijke zichtbaarheid regelen daarnaast de Restrictions. Controleer bij twijfel met een testaccount van de doelgroep.
Troubleshooting
Ik zie geen „Publiceren"-knop, alleen „Vrijgave aanvragen".
Dan ontbreekt u het canPublish-recht. Dat is met opzet (vier-ogenprincipe) — een reviewer/admin geeft vrij.
Gepubliceerd, maar gebruikers zien niets.
Bijna altijd een Restriction of een ontbrekende categorie. Ontvanger/zichtbaarheid met testaccount controleren.
Ik moet een gepubliceerde pagina corrigeren.
Bewerk hem in de Edit-Mode; afhankelijk van de configuratie doorloopt de wijziging opnieuw de vrijgave. Voor grotere verbouwingen eventueel archiveren en met refresh opnieuw opzetten.
Verwant
Ter afsluiting van het hoofdstuk: How to: perfecte inhoud.
Aprobare & publicare
De la ciornă la pagina vizibilă: CAMPUS are un flux de aprobare clar, astfel încât doar conținutul verificat să ajungă live. Această pagină explică stările, rolurile, procesul concret și ce ar trebui să verificați înainte de publicare.
De ce există un flux de lucru
Fără o aprobare reglementată, fiecare ciornă ajunge imediat la utilizatori — cu greșeli de tastare, propoziții pe jumătate și afirmații neverificate. Fluxul separă lucrul de publicare: construiți în liniște, cineva verifică, apoi conținutul devine live. Astfel se protejează calitatea și încrederea.
Stările & tranzițiile
Fiecare Product parcurge stări; tranzițiile au nume fixe (și în API):
Din starea Arhivat, tranziția refresh readuce un Product în editare. Publicarea directă (publish/activate) este posibilă dacă aveți dreptul necesar.
Cine ce poate face? (Reviewer)
Dacă puteți publica personal sau doar „solicita aprobarea" depinde de drepturile dumneavoastră (câmpul canPublish). Verificarea & aprobarea le preia rolul Reviewer — un drept activabil (vezi Roluri & drepturi). Astfel apare un principiu curat al celor patru ochi: editorul creează, Reviewer aprobă.
Cum se face concret
- FinalizațiVerificați conținutul, limba/limbile, categoriile/etichetele și accesul.
- Solicitați aprobareaLa Product, setați starea pe „Solicită aprobarea" (
request_approval). - Lăsați să fie verificatUn Reviewer vede solicitarea, verifică și aprobă (
approve) — sau o returnează cu observații. - PublicațiDupă aprobare, Product-ul devine activ și vizibil pentru grupul-țintă.
- Întreținere ulterioarăArhivați conținutul învechit; readuceți-l pentru revizuire cu
refresh.
Listă de verificare înainte de publicare
- Toate limbile? Titlu, lead și conținut pentru fiecare limbă activă (cel puțin DEFAULT).
- Categorii & etichete? Altfel conținutul se găsește greu.
- Acces corect? Public, grup sau Restriction-Preset conform dorinței.
- Imagine hero & previzualizare? Prima impresie contează.
- Linkuri & medii? Funcționează, asset-uri corecte, drepturi clarificate.
Vizibilitate ≠ autorizare. Publicarea face un Product „live" — vizibilitatea reală este controlată suplimentar de Restrictions. La îndoială, verificați cu un cont de test al grupului-țintă.
Troubleshooting
Nu văd un buton „Publicare", ci doar „Solicită aprobarea".
Atunci vă lipsește dreptul canPublish. Este intenționat (principiul celor patru ochi) — un Reviewer/Admin aprobă.
Publicat, dar utilizatorii nu văd nimic.
Aproape întotdeauna este o Restriction sau o categorie lipsă. Verificați destinatarii/vizibilitatea cu un cont de test.
Trebuie să corectez o pagină publicată.
Editați-o în Edit-Mode; în funcție de configurație, modificarea trece din nou prin aprobare. Pentru remanieri mai mari, eventual arhivați și reconstruiți cu refresh.
Înrudite
Pentru finalul capitolului: How to: conținut perfect.
Έγκριση & δημοσίευση
Από το προσχέδιο στην ορατή σελίδα: το CAMPUS διαθέτει μια σαφή ροή έγκρισης, ώστε να δημοσιεύεται μόνο ελεγμένο περιεχόμενο. Αυτή η σελίδα εξηγεί τις καταστάσεις, τους ρόλους, τη συγκεκριμένη διαδικασία και τι πρέπει να ελέγξετε πριν τη δημοσίευση.
Γιατί υπάρχει ροή εργασίας
Χωρίς ρυθμισμένη έγκριση, κάθε προσχέδιο καταλήγει αμέσως στους χρήστες — με ορθογραφικά λάθη, μισές προτάσεις και μη ελεγμένες δηλώσεις. Η ροή εργασίας διαχωρίζει το Επεξεργασία από τη Δημοσίευση: χτίζετε με την ησυχία σας, κάποιος ελέγχει, και μετά δημοσιεύεται. Έτσι προστατεύονται η ποιότητα και η εμπιστοσύνη.
Οι καταστάσεις & οι μεταβάσεις
Κάθε Product διέρχεται από καταστάσεις· οι μεταβάσεις έχουν σταθερά ονόματα (και στο API):
Από την κατάσταση Αρχειοθετημένο, η μετάβαση refresh επαναφέρει ένα Product στην επεξεργασία. Η άμεση δημοσίευση (publish/activate) είναι δυνατή, εφόσον έχετε το σχετικό δικαίωμα.
Ποιος επιτρέπεται να κάνει τι; (Reviewer)
Το αν μπορείτε να δημοσιεύετε εσείς ή μόνο να «αιτηθείτε έγκριση» εξαρτάται από τα δικαιώματά σας (πεδίο canPublish). Τον έλεγχο & την έγκριση αναλαμβάνει ο ρόλος Reviewer — ένα ενεργοποιήσιμο δικαίωμα (βλ. Ρόλοι & δικαιώματα). Έτσι δημιουργείται μια καθαρή αρχή των τεσσάρων ματιών: ο Editor δημιουργεί, ο Reviewer εγκρίνει.
Πώς γίνεται στην πράξη
- ΟλοκλήρωσηΕλέγξτε περιεχόμενο, γλώσσα(ες), κατηγορίες/tags και πρόσβαση.
- Αίτημα έγκρισηςΣτο Product ρυθμίστε την κατάσταση σε «Αίτημα έγκρισης» (
request_approval). - ΈλεγχοςΈνας Reviewer βλέπει το αίτημα, το ελέγχει και το εγκρίνει (
approve) — ή το επιστρέφει με υποδείξεις. - ΔημοσίευσηΜετά την έγκριση, το Product γίνεται ενεργό και ορατό για το κοινό-στόχο.
- Μετέπειτα συντήρησηΑρχειοθετήστε ό,τι είναι απαρχαιωμένο· για επεξεργασία επαναφέρετέ το με
refresh.
Λίστα ελέγχου πριν τη δημοσίευση
- Όλες οι γλώσσες; Τίτλος, lead και περιεχόμενο ανά ενεργή γλώσσα (τουλάχιστον DEFAULT).
- Κατηγορίες & tags; Αλλιώς το περιεχόμενο βρίσκεται δύσκολα.
- Σωστή πρόσβαση; Δημόσιο, ομάδα ή Restriction-Preset όπως επιθυμείτε.
- Εικόνα Hero & προεπισκόπηση; Η πρώτη εντύπωση μετράει.
- Σύνδεσμοι & πολυμέσα; Λειτουργούν, σωστά assets, ξεκαθαρισμένα δικαιώματα.
Ορατότητα ≠ εξουσιοδότηση. Η δημοσίευση κάνει ένα Product «live» — την πραγματική ορατότητα την ελέγχουν επιπλέον τα Restrictions. Σε περίπτωση αμφιβολίας, ελέγξτε με έναν δοκιμαστικό λογαριασμό του κοινού-στόχου.
Αντιμετώπιση προβλημάτων
Δεν βλέπω κουμπί «Δημοσίευση», μόνο «Αίτημα έγκρισης».
Τότε σας λείπει το δικαίωμα canPublish. Αυτό είναι σκόπιμο (αρχή των τεσσάρων ματιών) — ένας Reviewer/Admin εγκρίνει.
Δημοσιευμένο, αλλά οι χρήστες δεν βλέπουν τίποτα.
Σχεδόν πάντα πρόκειται για ένα Restriction ή για μια απούσα κατηγορία. Ελέγξτε παραλήπτες/ορατότητα με δοκιμαστικό λογαριασμό.
Πρέπει να διορθώσω μια δημοσιευμένη σελίδα.
Επεξεργαστείτε την στο Edit-Mode· ανάλογα με τη διαμόρφωση, η αλλαγή περνά ξανά από την έγκριση. Για μεγαλύτερες αναδιαμορφώσεις, ενδεχομένως αρχειοθετήστε και ξεκινήστε από την αρχή με refresh.
Σχετικά
Για την ολοκλήρωση του κεφαλαίου: How to: τέλειο περιεχόμενο.
الاعتماد والنشر
من المسودة إلى الصفحة المرئية: يعرف CAMPUS سير عمل واضحًا للاعتماد، بحيث لا يُنشر سوى المحتوى الذي تمت مراجعته. تشرح هذه الصفحة الحالات والأدوار والسير الفعلي وما ينبغي أن تتحقق منه قبل النشر.
لماذا يوجد سير عمل
من دون اعتماد منظم، تصل كل مسودة إلى المستخدمين على الفور — مع الأخطاء الإملائية والجمل الناقصة والعبارات غير المراجَعة. يفصل سير العمل بين العمل والنشر: تبني بروية، يراجع شخص ما، ثم يُنشر المحتوى. هذا يحمي الجودة والثقة.
الحالات والانتقالات
يمر كل Product بحالات؛ وللانتقالات أسماء ثابتة (أيضًا في API):
من حالة مؤرشف يعيد الانتقال refresh أي Product إلى التحرير. النشر المباشر (publish/activate) ممكن إذا كنت تملك الحق لذلك.
من يحق له ماذا؟ (Reviewer)
سواء كان يحق لك النشر بنفسك أو مجرد «طلب الاعتماد»، فذلك يعتمد على حقوقك (الحقل canPublish). أما المراجعة والموافقة فتتولاها الرتبة Reviewer — وهو حق قابل للتفعيل (انظر الأدوار والحقوق). وهكذا ينشأ مبدأ سليم لمراجعة الأربع عيون: المحرر ينشئ، والـReviewer يعتمد.
كيف يتم ذلك عمليًا
- الإنهاءتحقق من المحتوى واللغة (اللغات) والفئات/الوسوم والوصول.
- طلب الاعتماداضبط حالة الـProduct على «طلب الاعتماد» (
request_approval). - إتاحة المراجعةيرى الـReviewer الطلب ويراجعه ويعتمده (
approve) — أو يعيده مع ملاحظات. - النشربعد الاعتماد يصبح الـProduct نشطًا ومرئيًا للفئة المستهدفة.
- الصيانة لاحقًاأرشِف ما تقادم؛ وأعِده للتعديل بـ
refresh.
قائمة تحقق قبل النشر
- كل اللغات؟ العنوان والمقدمة والمحتوى لكل لغة نشطة (على الأقل DEFAULT).
- الفئات والوسوم؟ وإلا سيصعب العثور على المحتوى.
- الوصول صحيح؟ عام أو للمجموعة أو Restriction-Preset كما هو مطلوب.
- صورة الغلاف والمعاينة؟ الانطباع الأول مهم.
- الروابط والوسائط؟ تعمل، والأصول صحيحة، والحقوق موضّحة.
الظهور ≠ الصلاحية. النشر يجعل الـProduct «حيًا» — أما الظهور الفعلي فتتحكم فيه إضافةً إلى ذلك الـRestrictions. تحقق عند الشك باستخدام حساب اختبار من الفئة المستهدفة.
حل المشكلات
لا أرى زر «النشر»، بل فقط «طلب الاعتماد».
عندئذٍ ينقصك حق canPublish. هذا مقصود (مبدأ الأربع عيون) — يقوم Reviewer/Admin بالاعتماد.
نُشر، لكن المستخدمين لا يرون شيئًا.
في الغالب يكون السبب Restriction أو فئة ناقصة. تحقق من المستلمين/الظهور بحساب اختبار.
يجب أن أصحح صفحة منشورة.
حرّرها في Edit-Mode؛ وحسب الإعداد قد يمر التعديل بالاعتماد من جديد. للتعديلات الكبيرة يمكن الأرشفة وإعادة البناء بـrefresh.
ذات صلة
لختام الفصل: كيف: محتوى مثالي.
审核与发布
从草稿到可见页面：CAMPUS 拥有清晰的审核流程，确保只有经过检查的内容才能上线。本页说明各种状态、角色、具体流程，以及在发布前应检查的事项。
为什么需要流程
没有规范的审核，每一份草稿都会立即出现在用户面前——带着拼写错误、半截句子和未经核实的表述。该流程将编辑与发布分开：您从容地构建，有人负责检查，然后才上线。这样保护了质量与信任。
状态与转换
每个 Product 都会经历若干状态；这些转换有固定的名称（在 API 中也是如此）：
从已归档状态，转换 refresh 会将 Product 重新拉回编辑状态。如果您拥有相应权限，也可以直接发布（publish/activate）。
谁可以做什么？（Reviewer）
您是可以自行发布，还是只能“请求审核”，取决于您的权限（字段 canPublish）。检查与批准由 Reviewer 角色负责——这是一项可启用的权限（参见角色与权限）。由此形成清晰的双人复核机制：编辑创建，Reviewer 审批。
具体操作
- 完成制作检查内容、语言、类别/标签和访问权限。
- 请求审核在 Product 上将状态设为“请求审核”（
request_approval）。 - 交由审核Reviewer 看到请求，进行检查并批准（
approve）——或附带说明退回。 - 发布批准后，Product 变为激活状态，对目标群体可见。
- 后续维护将过时内容归档；如需修改，用
refresh拉回。
发布前检查清单
- 所有语言？每种启用语言的标题、导语和内容（至少 DEFAULT）。
- 类别与标签？否则内容很难被找到。
- 访问权限正确？按需设为公开、群组或 Restriction-Preset。
- 主视觉图与预览？第一印象很重要。
- 链接与媒体？可正常使用、Asset 正确、版权已明确。
可见 ≠ 有权限。发布使 Product“上线”——实际可见性还额外由 Restrictions 控制。如有疑问，请用目标群体的测试账号检查。
故障排除
我看不到“发布”按钮，只有“请求审核”。
那说明您缺少 canPublish 权限。这是有意为之（双人复核机制）——由 Reviewer/管理员审批。
已发布，但用户看不到。
几乎总是某个 Restriction 或缺失的类别所致。请用测试账号检查接收者/可见性。
我需要修改一个已发布的页面。
请在 Edit-Mode 中编辑；根据配置，修改可能会再次经过审核流程。较大的改动可考虑归档后用 refresh 重新设置。
相关内容
本章收尾：如何打造完美内容。