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

Show last authors
1 {{toc start="2"/}}
2
3 == Purpose ==
4
5 * Warn users/admins that:
6 ** Modifying an extension page might have bad impact on the extension behavior
7 ** Modifying an extension might make more much more difficult to upgrade it
8
9 (% class="row" %)
10 (((
11 (% class="col-xs-6 col-md-8" %)
12 (((
13 == Requirements ==
14
15 {{usecase}}
16 Edit modes: we might want to block/warn on some modes (wiki, objects) while permitting the other modes (Inline, WYSIWYG)
17 {{/usecase}}
18
19 {{usecase}}
20 Some edits might be programmatic, is there a way to forbid / warn on those?
21 {{/usecase}}
22
23 {{usecase}}
24 Warn the user that he is editing a special page from the start. Don't let the user find out it in a second step or at upgrade
25 {{/usecase}}
26
27 {{usecase}}
28 If changes have been made to extension pages, be able to revert to the initial state (by History or EM)
29 {{/usecase}}
30
31 {{usecase}}
32 At upgrade, if extension pages have changes, be able to backup them in a separate location, while replacing them with the new extension version
33 {{/usecase}}
34
35 {{usecase}}
36 Find a solution that can be applied in a consistent manner over edit, move, delete actions
37 {{/usecase}}
38
39 {{usecase}}
40 Extensions should keep separate technical/code pages, from content/demo pages and from configurations.
41 {{/usecase}}
42
43 {{usecase}}
44 Developers should be able to still edit the extension pages in a easy way
45 {{/usecase}}
46
47 {{usecase}}
48 Provide a report in EM about the extensions that have modified pages, before running the upgrade
49 {{/usecase}}
50
51 {{usecase}}
52 If there are configurations that need to be added by users, rewrite the extension so that these changes don't impact the upgrade
53 {{/usecase}}
54 )))
55
56 (% class="col-xs-6 col-md-4" %)
57 (((
58 == Ideas: Warning location ==
59
60 * Notification - missable
61 * Banner (with UIX)
62 ** permanent
63 ** dismissible
64 * Editor
65 ** Notification widget, like Save messages
66 ** Read-only textarea
67 ** Save reject
68 ** Warning above save button
69 ** Warning above title
70 * Panel with a warning macro
71 * Modal
72 * Warning macro on action template (edit, move)
73 * Step before, like lock mechanism
74 * Step after, like delete extension
75 )))
76 )))
77
78 == Alternatives ==
79
80 (% class="row" %)
81 (((
82 (% class="col-xs-6 col-md-4" %)
83 (((
84 === Block changes ===
85
86 * No matter the user type (user, admin or developer), don't allow editing of extension pages
87 ** If someone wants to extend the application it should fork it or use it as a dependency
88 )))
89
90 (% class="col-xs-6 col-md-4" %)
91 (((
92 === Protect changes ===
93
94 * Disallow edits for users / admins, but allow to developers
95 ** Consider developers as advanced users and consider they know what they are doing
96 )))
97
98 (% class="col-xs-6 col-md-4" %)
99 (((
100 === Discourage changes ===
101
102 * Warn all editors about the consequences, but don't disallow edits
103 )))
104 )))
105
106 == Extension Structure ==
107
108 (% class="row" %)
109 (((
110 (% class="col-xs-6 col-md-4" %)
111 (((
112 === Protected pages ===
113
114 Examples: Code, Technical pages (A)
115
116 * Should not be editable by users
117 ** Decide if developers need a preference in order to edit
118 )))
119
120 (% class="col-xs-6 col-md-4" %)
121 (((
122 === Indirectly modified pages ===
123
124 Examples: XWikiPreferences, badly designed application not generating configuration page
125
126 * Should be protected from direct edit and only modifiable trough UI by default
127 )))
128
129 (% class="col-xs-6 col-md-4" %)
130 (((
131 === Directly modified pages ===
132
133 Examples: Demo content, flavor home page
134
135 * Content pages should be editable by normal users
136 ** Demo content should be packaged separate and allow deletion
137 ** Content pages could be autogenerated, but a huge pain to maintain without even talking about dealing with translations
138 )))
139 )))
140
141 * Move is forbidden in all cases.
142 * Edition is allowed in C.
143 * Deletion is allowed in C (?).
144
145 * A user can be put in "developer mode" to disable all protections (when actually writing applications which is something that happen in the wiki too). Probably keep a warning on the side.
146
147 == How to type extension pages ==
148
149 === XObject based markers ===
150
151 An xobject indicating how an extension page is supposed to be protected/merged:
152
153 * forbidden to directly modify it, 3 ways merge during upgrades
154 * forbidden to directly modify it, don't touch it during upgrade if there is any change
155 * forbidden to directly modify it, don't touch it during upgrade (change or not)
156 * any direct modification is allowed, don't touch it during upgrades if there is any change
157 * any direct modification is allowed, don't touch it during upgrades (change or not)
158 * direct edit allowed but delete is forbidden
159 * ...
160
161 Default being: forbidden to directly modify it, 3 ways merge during upgrade. That's the most common use case by far which allow configuring only a few pages.
162
163 === Descriptor based markers ===
164
165 Same as previous but indicated in the descriptor to not pollute the pages.
166
167 === Rights ===
168
169 Use rights to forbid edit on some pages but it does not covers non advanced admin use case or what do do during upgrade.
170
171 == Proposals ==
172
173 === Proposal 1: Protect changes ===
174
175 (% class="row" %)
176 (((
177 (% class="col-xs-6 col-md-4" %)
178 (((
179 * For forbidden direct edit pages: No edit button at all
180 * Not forbidden direct edit pages: No complains
181 )))
182
183 (% class="col-xs-6 col-md-4" %)
184 (((
185 ==== Proposal 1.1: User Preferences ====
186
187 * Introduce an User Profile preference that can be set and allow extension page editing. Default it should be false. Developers should activate this preference.
188
189 ==== Proposal 1.3: Cookie ====
190
191 * In order to facilitate for developers the option selected, remember it in a cookie
192 )))
193
194 (% class="col-xs-6 col-md-4" %)
195 (((
196 ==== Proposal 1.2: XWikiDevGroup group ====
197
198 * Create a default group called XWiki.XWikiDevGroup
199 * Administrators could add users interested in developing / modifying applications in that particular group
200 )))
201 )))
202
203 (% class="row" %)
204 (((
205 (% class="col-xs-6 col-md-4" %)
206 (((
207
208 )))
209
210 (% class="col-xs-6 col-md-4" %)
211 (((
212
213 )))
214 )))
215
216 === Proposal 2: Discourage changes ===
217
218 (% class="row" %)
219 (((
220 (% class="col-xs-6 col-md-4" %)
221 (((
222 * Warn all editors about the consequences, but don't disallow edits
223
224 * If we pick Proposal 1 and protect changes for users and admins, than this proposal would apply only for the Developer persona
225 )))
226
227 (% class="col-xs-6 col-md-4" %)
228 (((
229
230 )))
231
232 (% class="col-xs-6 col-md-4" %)
233 (((
234
235 )))
236 )))
237
238 ==== Proposal 2.0: Mark Edit button differently ====
239
240 (% class="row" %)
241 (((
242 (% class="col-xs-6 col-md-4" %)
243 (((
244 * On extension pages where actions are discouraged, mark the actions in a special manner allowing the users to know in advanced they will get a warning without the need to perform a click
245
246 * We should be careful when marking the actions differently in order to be recognisable but not drawing too much attention on them and transforming the action in an invitation instead of a warning
247
248 * The problem is that the users could still edit the pages by following Index / AWM livetable actions or directly from the URL
249 )))
250
251 (% class="col-xs-6 col-md-4" %)
252 (((
253 Before
254 [[[[image:before_edit_advanced.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:before_edit_advanced.png]]
255 )))
256
257 (% class="col-xs-6 col-md-4" %)
258 (((
259 After
260
261 ==== Proposal 2.0.1: Lock ====
262
263 (% class="row" %)
264 (((
265 (% class="col-xs-6 col-md-6" %)
266 (((
267 [[[[image:after_edit_advanced_1.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:after_edit_advanced_1.png]]
268 )))
269
270 (% class="col-xs-6 col-md-6" %)
271 (((
272 [[[[image:after_edit_advanced_1_expanded.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:after_edit_advanced_1_expanded.png]]
273 )))
274 )))
275
276 ==== Proposal 2.0.2: Warning Color icon ====
277
278 (% class="row" %)
279 (((
280 (% class="col-xs-6 col-md-6" %)
281 (((
282 [[[[image:after_edit_advanced_2.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:after_edit_advanced_2.png]]
283 )))
284
285 (% class="col-xs-6 col-md-6" %)
286 (((
287 [[[[image:after_edit_advanced_2_expanded.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:after_edit_advanced_2_expanded.png]]
288 [[[[image:after_edit_actions_2_expanded.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:after_edit_actions_2_expanded.png]]
289 )))
290 )))
291
292 ==== Proposal 2.0.3: Warning Color icon + text ====
293
294 (% class="row" %)
295 (((
296 (% class="col-xs-6 col-md-6" %)
297 (((
298 [[[[image:after_edit_advanced_3.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:after_edit_advanced_3.png]]
299 )))
300
301 (% class="col-xs-6 col-md-6" %)
302 (((
303
304 )))
305 )))
306 )))
307 )))
308
309 ==== Proposal 2.1: Modal on Edit button ====
310
311 (% class="row" %)
312 (((
313 (% class="col-xs-6 col-md-4" %)
314 (((
315 * When the user is pressing the "Edit" button display a modal warning the user about the type of page he want to edit
316 )))
317
318 (% class="col-xs-6 col-md-4" %)
319 (((
320 Before
321 [[[[image:before_AllDocs_view.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:before_AllDocs_view.png]]
322 )))
323
324 (% class="col-xs-6 col-md-4" %)
325 (((
326 {{gallery}}
327 image:after_21_modal.png
328 image:after_edit_lock.png
329 image:after_edit_warning.png
330 {{/gallery}}
331
332 ==== Modal 1 ====
333
334 * Similar to what was used on the Delete step
335 [[[[image:modal_P1.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:modal_P1.png]]
336
337 ==== Modal 2 ====
338
339 * According to Bootstrap modal structure
340 [[[[image:modal_P2.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:modal_P2.png]]
341 )))
342 )))
343
344 ==== Proposal 2.2: Modal when entering Edit mode ====
345
346 (% class="row" %)
347 (((
348 (% class="col-xs-6 col-md-4" %)
349 (((
350 * Display a modal when entering the Edit mode. If the user is pressing "Cancel" he will still be able to view the syntax version, hidden status, syntax code, but the editor and save buttons will be disabled
351
352 * Proposal 2.2.1
353 ** On "Cancel" go the user in View mode
354
355 * Proposal 2.2.2
356 ** On "Cancel" show the editor in read-only mode
357 )))
358
359 (% class="col-xs-6 col-md-4" %)
360 (((
361 Before
362 [[[[image:before_AllDocs_edit.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:before_AllDocs_edit.png]]
363 )))
364
365 (% class="col-xs-6 col-md-4" %)
366 (((
367 {{gallery}}
368 image:after_22_modal.png
369 image:after_22_editor.png
370 {{/gallery}}
371 )))
372 )))
373
374 ==== Proposal 2.3: Warning step before edit ====
375
376 (% class="row" %)
377 (((
378 (% class="col-xs-6 col-md-4" %)
379 (((
380 * Similar to what we do when forcing Edit mode, we could display a warning before entering edit mode
381 )))
382
383 (% class="col-xs-6 col-md-4" %)
384 (((
385
386 )))
387
388 (% class="col-xs-6 col-md-4" %)
389 (((
390 After
391 [[[[image:after_23.png||style="border:1px solid #E8E8E8" width="auto"]]>>attach:after_23.png]]
392 )))
393 )))
394
395
396
397 (% class="row" %)
398 (((
399 (% class="col-xs-6 col-md-4" %)
400 (((
401
402 )))
403
404 (% class="col-xs-6 col-md-4" %)
405 (((
406
407 )))
408
409 (% class="col-xs-6 col-md-4" %)
410 (((
411
412 )))
413 )))
414
415 === Proposal 3: Mix of protect and Discourage ===
416
417 * basic user: no edit button
418 * advanced user: highly discouraged
419 * developers: non blocker warning

Get Connected