Refactoring Admin.WebHome

Design: Improve Wiki Administration

Proposal : Seamless wiki & space admin

Layout proposals

• Proposal 1, Admin in view mode with left navigation menu
• Proposal 2, Admin in view mode without left navigation menu
• Proposal 3, Admin in edit mode with a navigation panel
• Proposal 4, Admin in edit mode without a navigation panel
• Space selection

Wiki/Space Administration options availability

Section	Option	Wiki level	Space level
General was: Parameters
	Multi Lingual: YesNo
	Languages : input
	Default Language : input
	Default Editor to use : TextWysiwyg NEW (moved from Editing)
	Admin email : input NEW (moved from registration)
	Outgoing SMTP Server : input NEW (moved from registration)
	Always authenticate on viewing (moved)
	Always authenticate on editing (moved)
	Check Active fields for user authentication: select (moved)
Editing
	Default Editor to use : TextWysiwyg (moved)
	Editor Box Width (characters) : input (deprecated)
	Editor Box Height (lines) : input (deprecated)
Presentation was: presentation + skin
	Skin : input Customiz
	Default Stylesheet: input
	Left Panels: input
	Right Panels: input
	Show Left Panels : YesNo
	Show Right Panels : YesNo
	Browser Title Bar Text : input
	Version : input
	Copyright notice : input
	HTTP Meta Information : textarea
Panels NEW
	Panel wizard
Registration was: registration
	Use email verification : YesNo
	Check Active fields for user authentication: select
	Validation e-Mail Content : textarea
	Confirmation e-Mail Content : textarea
	Invitation eMail Content : textarea
	Admin email : input
	Outgoing SMTP Server : input
Users
Groups
Rights
	Deny guests the right to view pages (will override spaces/pages settings) : YesNo was: Always authenticate on viewing in Parameters
	Deny guests the right to edit pages (will override spaces/pages settings) : YesNo was: Always authenticate on editing in Parameters
Import / Export was: Import + Export
Programming was: advanced
	Macro Languages : input
	Velocity Macro Pages : input
	Groovy Macro Pages : input
	Macro Mapping : textarea
	Notification Pages : input
	Internationalization Document Bundles : input

Implementation proposal

• removing admin templates
• A main administration sheet : XWiki.AdminSheet (may be with cascading admin sheets beyond)
• XWiki.WebHome = direct links (with big icons) to admin categories (a la Windows control panel)
• Inclusion of XWiki.AdminSheet in XWikiPreferences (global prefs)
• Inclusion of XWiki.AdminSheet in all WebPreferences (quick access to space admin)

Pros

• No more admin templates
• No need to worry about the administration layout when building a custom skin
• Pages built the wiki way
• There are also discussions about a lesser differentiated edit mode, let's start with the administration
• Abitility to include the PanelWizard in the administration

Cons

• Need to search the drawbacks

Current XWiki.WebHome, and why we have to replace it

• Users
• Groups
• Recent Members

• Categories
• Article Sheet
• Article Template

• Photos

• Web RSS Feed
• Search RSS Feed
• Blog RSS Feed
• Tags RSS Feed

• Panels
• Panels Wizard

• Copy Document
• Statistics

Technical details & status

The administration application is currently being implemented in the following way:

• admin.vm template

• from all the old admin templates, only admin.vm, adminskin.vm and adminactions.vm still exists (not sure wheather the last 2 are neccessary somewhere else)
• users and groups new interface will appear only in the administration sub-sheets (XWiki.UsersSheet, XWiki.GroupsSheet)
• rightsUI.vm stays, since we need to set rights per document even in an empty wiki or when no admin app is installed
• admin.vm will be used to determine if we administrate globally (editor=globaladmin) or per space (editor=spaceadmin) and the current section in the menu
• admin.vm is also taking care to include the XWiki.AdminSheet and the XWiki.XWikiPreferences object at global and space level (WebPreferences)
• admin.vm will display only the old UI for Import & Export sections in an empty wiki

• XWiki.AdminSheet

• will contain the main UI of the administration
• will also contain the displayed sections in the menu (the fixed ones like Rights, Users etc) and the hard-coded links to admin pages from other apps (currently only Panels, Blog, Photos)
• depending what section of the menu is active, the AdminSheet will include the section sheet available for the fixed sections (rights, programming etc.) or the admin page, if exists, in case of other apps.

• XWiki.AdminFieldsDisplaySheet

• all the section sheet which display several fields from XWiki.XWikiPreferences object will include this one, which contains the general code for displaying the necessary form

• XWiki.AdminInlineSheet

• all the admin pages from other app. can be edited inside the administration UI
• this means including the inline display inside the admin one
• this sheet contains a modified version of editinline.vm (it is modified because the redirects are done to /admin/Blog/Categories?editmode=inline instead of /inline/Blog/Categories)
• BUG HERE: after editing an admin page (for example Blog.Categories) and pressing PREVIEW, the modifs can be correctly seen, but when when pressing BACK TO EDIT, the inline form is not correctly updated (tried to update the form with $doc.updateObjectsFromRequest). Searching for a workaround here...

• Other section sheets

• contain only an array with the name of the fields from XWiki.XWikiPreferences object which need to be displayed and will include the AdminDisplayFields sheet
• or include templates like rightsUI.vm, importinline.vm and exportinline.vm

• The links on XWiki.WebHome:

• are the same as the sections in the global admin
• copy document is moved and is placed at rename level
• statistics is moved as a link in the quicklinks panel