Re: [xwiki-devs] [Idea] Page Administration

single "Rights" UI screen with a checkbox to decide whether children are affected or not. This would avoid users picking the wrong UI *(just saw it happening in front of my eyes ).*

Hi, Here's my input on this... TL;DR: Don`t rewrite anything and don`t put "affect children" checkboxes under each option. Simply use a select to redirect from page admin

action and XWiki.AdminSheet on the current page) to space admin (XWiki.AdminSheet on the WebPreferences page, like it is now) and yes, store the preferences object in the page, like we do with rights as well. ATM, "edit" right is king in XWiki and I don`t think we are planning to change that very soon. Longer version: I am not sure what your aim is with this. My initial idea over this was that: 1) we would have a link/action in view mode that takes you to "Page Administration" (does not matter if it's a terminal or non-terminal document) 2) the user would be taken to the admin mode of the current page (i.e. /admin/Space/Page) 3) to access that mode, for page administration (WebHome or terminal document, so != WebPreferences), the user would need only "edit" rights (also due to our rights system's implementation of rights storage in wiki pages) 4) once there, the user sees the regular space administration sheet (XWiki.AdminSheet), but applied to the current page (!= WebPreferences). Thinking about it, I guess all the preferences for a space (at least the ones we have now), could be made available for individual pages as well.

could probably filter the sections displayed for the administration of a page (again, != WebPreferences), either statically, in the code, or dynamically, through some extension points... but we could leave that discussion for later (what we want to add/remove, if we want to do that, etc.). This means that yes, any configuration object (XWiki.XWikiPreferences or other) is stored in the actual page, just like we do for rights objects, document binding sheet objects, etc. 5) above the vertical sections menu, on the left, of the administration

[1], we would have a select-like input showing the user that he is currently on the Page Administration of document X (again, != WebPreferences) and where he can switch to go to the Page Administration

document X and its children (i.e. space administration, i.e. SpaceOfX.WebPreferences). Of course, if X is a terminal document (i.e. != WebHome), we either don`t show this select at all, or instead of a select we show a label informing the user that he is in the page administration

document X (but not showing options) OR, the lazier solution is to still show a select, but with only the 1 option (i.e. no option to administer page + children, since it's a terminal document). Yet another idea here

terminal documents would be to offer the 2nd option as administering the *parent* document and its children. 6) using the select-like control to switch to the page + children option would redirect to /admin/SpaceOfX/WebPreferences and from there we can switch back to page only and come back to /admin/SpaceOfX/WebHome. This switching back and forwards could be managed based on convention, but for terminal documents, if we go with the "parent + children" option (previously mentioned at point 5.), we would probably need a request parameter to be able to go back to the terminal document that took us there. Maybe we should just avoid the problem altogether for terminal documents and just interpret it as we are redirecting him to a different document altogether (the parent document), so we don`t have to bring him back as well, since in the parent document + children administration UI

will see as the second option in the select to go to the page administration only (of the parent document on which is will be then), so no connection with the terminal document's administration from which he arrived. 7) when switching to page + children administration, the /admin/ action currently requires "admin" right to access. IMO we should reconsider

since this implies that only wiki admins can access it and then give

regular users "admin" rights on spaces. However, we need to allow regular users to be able to administer spaces (which are now nested), so the requirement that a wiki level admin does the initial "blessing" of a

by adding "lower level" space admins is not feasable. The only solution I can think of ATM is to make the admin action function based on the "edit" right (for both regular and WebPreferences documents) and only care about the "admin" right on XWiki.XWikiPreferences. It does not make sense

to restrict page + children (i.e. space) customization only to wiki

and, IMO, it did not make sense before Nested Spaces either. There's a lot of text, but all I`m saying is to basically do less and

what we have instead of overcomplicating things :) Hope this helps, Eduard ---------- [1]

On Wed, Nov 4, 2015 at 6:54 PM, Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com&gt; wrote: > No more idea? > > 2015-11-02 16:35 GMT+01:00 Ecaterina Moraru (Valica) <

"Space for the > > > wall. > > > > > > Now we should go one step forward, and create a real page > administration, > > > that could work for both nested pages and terminal pages. > > > > > > There is a JIRA issue about this: > > http://jira.xwiki.org/browse/XWIKI-12497 > > > > > > I've written some ideas about the implementation that you could

: know > > > about > > > > it, you can go to XWiki/XWikiPreferences?viewer=history to

> > > > problematic changes, but for the average admin this feature isn't > > exposed > > > > well, event though it's quite useful. > > > > > > > > Food for thoughts, > > > > > > > > Guillaume > > > > > > > > On Fri, Aug 9, 2013 at 5:59 PM, Ecaterina Moraru (Valica) < > > > > valicac(a)gmail.com > > > > > wrote: > > > > > > > > > Hi devs, > > > > > > > > > > So this proposal appeared in some of my proposals but right

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs