Publication process

There is an internal PBL wiki and an external wiki. The external wiki is a subset of the internal wiki and is meant to be viewed by webusers. The implementation will probably (discussion item) be by installing one wiki inside the firewall and one wiki outside the firewall. The external wiki will be filled by an import of pages from the internal wiki and periodically updated.

• Internal wiki: This wiki is visible for PBL employees and external people that can login (?). In principle all contentpages are visible for all these people. However there will be a difference between viewers, writers and administrators, with more options available in this sequence. Viewers can view and discuss; writers will have an extended menu with functions to add content and may edit pages; administrators can change the structure and maintain user rights and use other maintenance functions.
• External wiki: This is the publishable part of the internal wiki and will be accessible for the outside world via a PBL URL.

INFO

CurrentFrameworkVersion: versie nummer voor de hele wiki CurrentVersion: versie nummer per pagina

[Approved Revs] Approverevisions' permission alleen voor alle pbl-ers, hiermee kan je kijken naar pagina’s die nog unaproved zijn (dit is dus de laatste versie).

De eigenschap $egApprovedRevsAutomaticApprovals staat op true. Hiermee worden alle wijzigingen automatisch op approved gezet en daarmee na een overdracht dus direct zichtbaar voor externe mensen.

How to handle changes

There are several situations with different solutions:

1. Minor text change
   • May be a correction or enhancement: Enter the changes in the wiki.
   • No increasing CurrentVersion number and no approvement procedure
2. Small adaptations to model components, substantial rewriting of a description or new pages
   • Tekst aanpassen
   • Na eerste save; de huidige (werk)- versie via the history tab op ‘unaproved’zetten.
   • Alle volgende wijzigingen blijven dan unaproved
   • Doe dit voor de hele set van pagina’s die je moet wijzigen.
   • Wanneer alle wijzigingen binnen deze set klaar zijn:
     • Start approvement procedure:
     • Check de gebundelde gewijzigde componenten en losse pagina’s
     • Currentversion nummer ophogen per component (niet per pagina) waar je wijziging aanbrengt
     • Redactionele slag:
     • Editing & aprove status toepassen

• If a page has no approved revision (this of course includes new pages), automatic approvals will not be applied.
• Current version nummer eigenschap toevoegen
• Pakt bij de hij bij de overdracht de laatste versie of de ‘aproved’versie? Waarschijnlijk geen probleem want externe personen hebben geen RevisionApprovalPermission en zien de laatste versie dus niet?! (moet dan wel de laaste ‘aproved’versie zien/geen lege pagina)

1. Substantial change resulting in a new version: When making a substantial change to your model by adding a submodule or changing the conceptual model, ****

1. Nieuwe release:
   • Maak een archief versie ( evt. in html/pdf vorm, liefst pdf vorm want dan verwachten mensen niet dat de links werken) zie extenties: collection en pdfbook
   • De hele wiki op unaproved zetten ($egApprovedRevsAutomaticApprovals = false;)
   • Wijzigingen slechts op het eind allemaal tegelijk approven.