Design
 Completed
 

Description

UI

Action Menu

Read related proposal Revised Menu

  • 'Page' entries
    • 'Watch Page'
    • 'Administer Page'
    •  _ 
    • 'Copy'
    • 'Rename'
    • 'Delete'

add 'Administer Page' entry that is going to be consistent with the other Wiki and Space entries
delete 'Share page by mail' is going to be moved to 'More actions' section

Administration Menu

  • 'Administration Page' entries
    • 'Page Elements' (not implemented yet)
    • 'Rights' (/edit/?editor=rights)
    • ... (any other functionality related to pages)

Administration Content

  • The purpose of this proposal is to assure consistency between Wiki, Space and Page administration

Implementation details

Current state

  • Nested Pages use the Space Administration already, which means the settings also concern the children, except for the rights thanks to a dedicated section that handle rights only for the page:

     Rights.png

  • Terminal pages do not have a proper administration.
  • The space settings are actually stored in a XWiki.XWikiPreferences object in the WebPreferences page.
    • so XWiki.XWikiPreferences is the class used for all the settings, but the location where the object is stored define their scope.
    • Note: At some point, the idea was to stop extending this class and create new ones (oner per application).
      • Problem: there is an interesting fail-back mechanism implemented for XWikiPreferences, with the usage of $xwiki.getSpacePreferences() and $xwiki.getUserPreferences(), that we should not lose

Actions

  • we should deprecate the "Space Administration", since the "space" concept have to disappear from the UI.

Constraints

  • we should be able to set a configuration for a page without affecting the children.
  • the migration should be easy (the settings are not lost).
  • Deprecating the XWikiPreferences class is too risky for the end of the 7.x cycle. We could do that in the next cycle.

Proposal 1

  • For now, we could introduce a Page Administration, which store the settings either in the page itself, or in the WebPreferences, depending if an "affect children" checkbox is selected or not.

    AffectChildren.png

  • Introduce $xwiki.getPagePreferences (or a Script Service instead).

Advantages

  • we re-use the existing system.
  • current settings stored in WebPreferences are handled properly, without the help of a migrator.
  • it works for terminal pages too (we just remove the "affect children" checkbox).

Drawbacks

  • we cannot have a different setting for the space (a.k.a all the children of the page) and for the page itself, since "affect children" only apply the same configuration to the space.
  • 2 locations to store the settings depending on the 'affect children' checkbox means more work to save the settings and is messy. It seems to be a bad design.

Proposal 2

  • introduce 2 administrations: "Page Administration" and "Page and Children Administration" (as we have now for the rights).
    • "Page Administration" use the XWiki.XWikiPreferences class stored in the page itself. "Page and Children Administration" use the XWiki.XWikiPreferences class stored in "Page.WebPreferences".
  • Introduce $xwiki.getPagePreferences (or a Script Service instead).

Advantages

  • we re-use the existing system.
  • current settings stored in WebPreferences are handled properly, without the help of a migrator.
  • it works for terminal pages too (we just remove the "affect children" checkbox).

Drawbacks

  • having two different administrations looks complicated.

General drawback about storing settings in the page itself

  • People having "edit" right on the page (but not "admin" right) can change the settings of the page using the object editor.
    • We could avoid that with a special handling in the save action (or with a listener).
    • We could also decide to store the settings of a page in an other page, called "${PageName}Preferences", but it means that a user should not create pages ending with "Preferences" (or any other suffix). Note that it can work for terminal pages too.
    • We could also decide it's ok, and say that the "admin" rights is only needed for the "affect children" checkbox since it's the only configuration that concerns more than the current page.

 

Tags:
Created by evalica on 2013/11/12 13:31
    

Get Connected