Is the problem of understanding inheritance of rights not a problem of displaying this to the user? The rights UI has always gotten me suspicious with the back-brain telling me "careful, there might be something above telling xwiki something else than the rights you are editing". Should this be solved by displaying the inherited rights when editing the rights of a page (but not allowing to edit them).
I guess this is complementary to an inheritance check-box. Paul > Guillaume "Louis-Marie" Delhumeau <mailto:[email protected]> > 12 novembre 2015 11:34 > Hello, and thanks Edy for your detailed answer. > > I'm OK with the idea to put the preferences (XWiki.XWikiPreferences) in the > page itself, just as we do for rights. > > However, I'm not sure that adding a switch "administrate this page / > administrate this page and its children" is a user-friendly solution. I > will quote Vincent, who has written a comment on the JIRA issue recently: > > Related to this, we also need to merge "Rights" and "Page Rights" under a >> 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 ).* >> > > It shows that users are already confused with the Rights UI, currently > split like you propose. > > I really think that, even if it's more complicated to implement (in > particular at the end of this cycle), it's more intuitive for the users to > have a checkbox-based solution. > > Do everybody think like Edy? What do you think? > > Thanks, > > Guillaume > > > 2015-11-05 16:09 GMT+01:00 Eduard Moraru <[email protected]>: > >> 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 >> > > > > Eduard Moraru <mailto:[email protected]> > 5 novembre 2015 16:09 > 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: > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > Guillaume "Louis-Marie" Delhumeau <mailto:[email protected]> > 4 novembre 2015 17:54 > No more idea? > > > > > Ecaterina Moraru (Valica) <mailto:[email protected]> > 2 novembre 2015 16:35 > 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 < > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > Guillaume "Louis-Marie" Delhumeau <mailto:[email protected]> > 29 octobre 2015 12:57 > 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 > > > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
