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.

Settings

• CurrentVersion: This is the version number of a page, given for each page individually
• CurrentFrameworkVersion: This is the version number of the Wiki as a whole
• Approved/ unapproved pages: The external wiki will only show approved pages. An unapproved page will be put to approved by the editors after the approval procedure, see the #How to handle changes section.
• Approve-revisions-permission: This permission allows you to look at pages which have the unapproved status. On default the latest approved page will be shown, but with this permission a link will be shown which gives access to the latest/unapproved version of the page. This permission is only given to people who have a user-login.
• $egApprovedRevsAutomaticApprovals: On default the setting $egApprovedRevsAutomaticApprovals is put on true. With this setting, each change will automatically be approved, and is thereby directly visible for external people. Automatic approvals will not be applied to new pages and pages which are actively put to the unapproved status. To know what to do when you want to make a change to the wiki, see the #How to handle changes section. For more information about the approve-revision-permission, see Approved Revs.

How to handle changes

There are several situations with different solutions:

1. Minor text change, either a correction or enhancement
   1. Enter the changes in the wiki.
   2. Do not increase the CurrentVersion number and do not apply the approvement procedure
2. Small adaptations to model components, substantial rewriting of a description or the creation of new pages
   1. Adjust the text
   2. After saving the first time; put the version you are currently working on to 'unapproved' via the history tab on the wiki-bar. All changes after this adjustment will stay on 'unapproved'
   3. Do this for the whole set of pages where you want to make adjustments. When all changes in this set of pages are done:
   4. Start the approvement procedure:
      • Check the combined set of changed components and individual pages
      • Increase the Currentversion number of each component you have changed (increase per component, not per page)
      • Editorial step for Editors:
        • Check the page and apply the 'approved' status when done
3. New release:
   1. Make an archief version
      • Pdf-format is probably the best, because people will not expect the links to work
      • See the extensions: collection and pdfbook
   2. Put the whole wiki on 'unaproved' by putting the setting $egApprovedRevsAutomaticApprovals to false
   3. When all changes are done, put all pages back to the approved status at the same time

overige tekst

• Current version nummer eigenschap toevoegen
• Pakt 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)