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#HImpl...

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

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+Appl... 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#HImpl...

...

...

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

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+Appl...

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#HImpl... 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+Appl...

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#HImpl...

I'm more in favor of the proposal 1.

WDYT?

Thanks for your time,

Guillaume

I've posted 2 screenshots (mock-ups) corresponding to your proposal: http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration#HProp... 2015-11-12 14:51 GMT+01:00 Eduard Moraru <[email protected]>:

On Thu, Nov 12, 2015 at 12:34 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

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.

IMO, the checkbox solution is not valid, because it does not differentiate between options applied for the current page only and options applied for the current page and its children. A better example is that you would not be able to set a property FALSE for the current page, but TRUE for the children by using a single control with an attached checkbox. Of course, things get more complicated once you have more complex options (static list, free text, etc.).

IMO, we should also try to avoid mixing the discussion about general Page Administration with the discussions on improvements of the RightsUI, since they are 2 already complex enough topics.

Thanks, Eduard

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+Appl...

...

...

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#HImpl...

...

...

...

...

...

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

-- 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