Introduce a new space which access is reserved to admins by default

[tmortagne]

I think we need to standardize a space dedicated to contain admin reserved pages. Each application (even in XWiki Standard) is doing its own thing and very often forget to properly protect those pages against access by a non admin user.

The same way we have a space (XWiki) which EDIT right is assigned to XWiki.XWikiAdminGroup by default (even if that group does not exist, only an admin can edit it because it breaks inheritance for EDIT right) I would like to standardize a space which VIEW right is reserved to XWiki.XWikiAdminGroup by default.

The idea would be to put in there two things:

• the UI pages which only a wiki admin is supposed to access (which are very often included in an admin section)
• the generated page holding admin configuration configured by the previous type of pages. Of course, it’s hard to move those (since their location is usually an API), so the idea is to define a standard to use for new pages

I propose the space XWiki.Admin.

WDYT ?

Here is my +1.

[CharpentierLucas]

@tmortagne

The idea would be to put in there two things:

And ONLY those two things, nothing else, right?

From what I understand, other admin reserved pages can go somewhere else under XWiki.

---

If that’s the case, +1 from me

Thank you for the proposal

[tmortagne]

@CharpentierLucas

And ONLY those two things, nothing else, right?

No, not only those two things, you can put whatever you want if you have a need.

Here, the idea is to define a rule for things that should be put there and not somewhere else (unless you have a very good reason, retro compatibility for example, in which case you take care of protecting them properly).

[mleduc]

@tmortagne

I propose the space XWiki.Admin.

+1 thanks

[vmassol]

Thanks for the proposal.

@tmortagne

I think we need to standardize a space dedicated to contain admin reserved pages. Each application (even in XWiki Standard) is doing its own thing and very often forget to properly protect those pages against access by a non admin user.

We do need a better organization and a standard location for extensions/applications.

See Application pages layout best practices - #5 by vmassol and especially the proposals at https://design.xwiki.org/xwiki/bin/view/Proposal/PageHierarchyLayout

IMO we need to vote about this (and if you have a new layout to propose, add a L6).

@tmortagne

I propose the space XWiki.Admin.

Just noting that XWiki.Admin is the user profile page of the default Admin user and nested pages under that user profile would “conflict” in several ways:

1. We have a proposal to add personal pages and the most natural location would be under the user profile page, see Personal Pages feature and https://design.xwiki.org/xwiki/bin/view/Proposal/PersonalPages
2. I don’t see why general admin pages should be located under the user profile page of a specific user (even if that user is an admin user).

So right now, I’m more -1 for this proposal, at least until we decide on Application pages layout best practices - #5 by vmassol (and possibly also on Personal Pages feature).

Thanks

[tmortagne]

@vmassol

I don’t see why general admin pages should be located under the user profile page of a specific user (even if that user is an admin user).

That’s indeed a good point. Even if that user rarely exists in production (it’s the default admin user only in the demo HSQLDB based package), it’s still not great.

@vmassol

until we decide on Application pages layout best practices - #5 by vmassol

I’m not sure voting for a list of complete layouts really is the best approach. I feel it’s much more manageable to discuss each type of pages (administration UI, administration data, public pages, hidden pages, extension data, user data, etc.) separately.

@vmassol

if you have a new layout to propose, add a L6

I don’t really have a full layout in mind, just wanted to discuss the concept of common location for administration pages.

[mflorea]

This sounds good for applications that have only global (wiki) configuration options, but we need to find better space name.

For applications that have both wiki and space level configuration options, we can’t put the administration section in this new space because it needs to be visible by space administrators. Then, if the application doesn’t (re)use the space/wiki preferences pages to store the configuration, it ends up handling the space and wiki configuration differently. It would be nice to have more consistency between wiki and space configuration.

Thanks,
Marius

[tmortagne]

@mflorea

For applications that have both wiki and space level configuration options, we can’t put the administration section in this new space because it needs to be visible by space administrators.

Definitely, and this thread is really focusing on wiki level administration for now.

Space level administration data is traditionally stored in the WebPreferences page, and I’m not sure we really have that many other choices without adding potential conflicts. For admin pages, it actually depends on what it is exactly (we don’t need the space admin to have view access to the page if it’s a UI extension, for example) but for included pages, yes they can’t be stored in the admin space which is discussed in this thread.