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 (/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. We 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 UI [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 of 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 of 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 for 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 he 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 this, since this implies that only wiki admins can access it and then give other 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 space 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 anyway to restrict page + children (i.e. space) customization only to wiki admins 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 reuse what we have instead of overcomplicating things :) Hope this helps, Eduard ---------- [1] http://extensions.xwiki.org/xwiki/bin/download/Extension/Administration+Application/global.png?width=960 On Wed, Nov 4, 2015 at 6:54 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote: > No more idea? > > 2015-11-02 16:35 GMT+01:00 Ecaterina Moraru (Valica) <[email protected]>: > > > Regarding implementation, we need to consider how we will export that > page > > and preserve it's preferences. > > > > Thanks, > > Caty > > > > On Thu, Oct 29, 2015 at 1:57 PM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > > > Hello. > > > > > > With the introduction of the Nested Pages, we need to remove the "Space > > > Administration" and to create a "Page Administration" instead. > > > > > > It's more or less already the case, a "page administration" is used for > > > Nested Pages, even if it's actually the space administration under 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 find > > there: > > > > > > > > > http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration#HImplementationdetails > > > > > > I'm more in favor of the proposal 1. > > > > > > WDYT? > > > > > > Thanks for your time, > > > > > > Guillaume > > > > > > 2013-08-13 11:24 GMT+02:00 Guillaume Lerouge <[email protected]>: > > > > > > > Hi Caty, > > > > > > > > looks good, and indeed it's good for consistency too. > > > > > > > > Which makes me think, it would be useful to display the history > feature > > > for > > > > the pages in the administration themselves. Right now, when you know > > > about > > > > it, you can go to XWiki/XWikiPreferences?viewer=history to rollback > > > > 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) < > > > > [email protected] > > > > > wrote: > > > > > > > > > Hi devs, > > > > > > > > > > So this proposal appeared in some of my proposals but right now I > > > > created a > > > > > proper Proposal/Idea mail for it. > > > > > > > > > > It's about having an 'Administer Page' section in the menus, > similar > > to > > > > the > > > > > 'Administer Wiki' and 'Administer Space' functionality. > > > > > > > > > > The 'Administer Page' will be accessible to global admins, page > > > creators > > > > > and users with (edit?/admin?) rights for the page. > > > > > > > > > > From what we currently have implemented it should contain the > 'Rights > > > > > Editor' (?editor=rights) at page level. > > > > > > > > > > In the future we could make 'Presentation', 'Page Elements' or > 'Panel > > > > > Wizard' to be more granular and be set at Page level (have > different > > > > panels > > > > > and style for just one page). > > > > > > > > > > Some screenshots at > > > > > > > > > > > > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PageAdministration > > > > > > > > > > Thanks, > > > > > Caty > > > > > _______________________________________________ > > > > > devs mailing list > > > > > [email protected] > > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > > > > > -- > > > Guillaume Delhumeau ([email protected]) > > > Research & Development Engineer at XWiki SAS > > > Committer on the XWiki.org project > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Delhumeau ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
