Wiki source code of Page Administration

Last modified by Vincent Massol on 2024/02/26 17:52

Show last authors
1 {{toc /}}
2
3 {{velocity}}
4 $xwiki.ssx.use("Improvements.WebHome")
5 $xwiki.ssx.use("Standards.WebHome")
6 $xwiki.ssx.use("Improvements.DocumentationFlavor")
7 {{/velocity}}
8
9 = UI =
10
11 == Action Menu ==
12
13 (% class="left column50 dashboardleft" %)
14 (((
15 {{info}}
16 Read related proposal [[Revised Menu>>Improvements.HomeMenu]]
17 {{/info}}
18
19 * 'Page' entries
20 ** 'Watch Page'
21 ** 'Administer Page'
22 ** __ _ __
23 ** 'Copy'
24 ** 'Rename'
25 ** 'Delete'
26
27 (+) 'Administer Page' entry that is going to be consistent with the other Wiki and Space entries
28 (-) 'Share page by mail' is going to be moved to 'More actions' section
29 )))
30
31 (% class="dashboardright right column50" %)
32 (((
33 {{gallery}}
34 image:[email protected]
35 image:MenuEdit.png
36 image:MenuMoreActions.png
37 image:[email protected]
38 {{/gallery}}
39 )))
40
41 (% class="clearfloats" %)
42 (((
43
44 )))
45
46 == Administration Menu ==
47
48 (% class="left column50 dashboardleft" %)
49 (((
50 * 'Administration Page' entries
51 ** 'Page Elements' //(not implemented yet)//
52 ** 'Rights' //(/edit/?editor=rights)//
53 ** ... (any other functionality related to pages)
54 )))
55
56 (% class="dashboardright right column50" %)
57 (((
58 {{gallery}}
59 image:VerticalMenuMinimal.png
60 image:VerticalMenuExtended.png
61 {{/gallery}}
62 )))
63
64 (% class="clearfloats" %)
65 (((
66
67 )))
68
69 == Administration Content ==
70
71 (% class="left column50 dashboardleft" %)
72 (((
73 * The purpose of this proposal is to assure consistency between Wiki, Space and Page administration
74 )))
75
76 (% class="dashboardright right column50" %)
77 (((
78 {{gallery}}
79 image:ContentElemens.png
80 image:ContentHistory.png
81 {{/gallery}}
82 )))
83
84 (% class="clearfloats" %)
85 (((
86
87 )))
88
89 = Implementation details =
90
91 == Current state ==
92
93 * 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: (((
94 {{image reference="Rights.png" /}}
95 )))
96 * Terminal pages do not have a proper administration.
97 * The space settings are actually stored in a XWiki.XWikiPreferences object in the WebPreferences page.
98 ** so XWiki.XWikiPreferences is the class used for all the settings, but the **location** where the object is stored define their scope.
99 ** Note: At some point, the idea was to stop extending this class and create new ones (oner per application).
100 *** 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
101
102 == Actions ==
103
104 * we should deprecate the "Space Administration", since the "space" concept have to disappear from the UI.
105
106 == Constraints ===
107
108 * we should be able to set a configuration for a page without affecting the children.
109 * the migration should be easy (the settings are not lost).
110 * Deprecating the XWikiPreferences class is too risky for the end of the 7.x cycle. We could do that in the next cycle.
111
112 == Proposal 1 ==
113
114 * 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. (((
115 {{image reference="AffectChildren.png" /}}
116 )))
117 * Introduce $xwiki.getPagePreferences (or a Script Service instead).
118
119 === Advantages ===
120
121 * we re-use the existing system.
122 * current settings stored in WebPreferences are handled properly, without the help of a migrator.
123 * it works for terminal pages too (we just remove the "affect children" checkbox).
124
125 === Drawbacks ===
126
127 * 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.
128 * 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.
129
130 == Proposal 2 ==
131
132 * introduce 2 administrations: "Page Administration" and "Page and Children Administration" (as we have now for the rights).
133 ** "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".
134 * Introduce $xwiki.getPagePreferences (or a Script Service instead).
135
136 {{gallery}}
137 image:AdminScopeSelector.png
138 image:AdminScopeSelector2.png
139 {{/gallery}}
140
141 === Advantages ===
142
143 * we re-use the existing system.
144 * current settings stored in WebPreferences are handled properly, without the help of a migrator.
145 * it works for terminal pages too (we just remove the "affect children" checkbox).
146
147 === Drawbacks ===
148
149 * having two different administrations looks complicated.
150
151 == General drawback about storing settings in the page itself ==
152
153 * People having "edit" right on the page (but not "admin" right) can change the settings of the page using the object editor.
154 ** We could avoid that with a special handling in the save action (or with a listener).
155 ** 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.
156 ** 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.

Get Connected