[xwiki-devs] [NS/ND] Permissions (was Re: [VOTE] Summary: NS, ND, Parent/Child)

One item we haven’t discussed here again (it was discussed in some other thread) are the Permissions. When we have ND, we need to decide how to set permissions for a non-terminal page.  Here’s what I propose: * Remove the current “Edit Rights” menu entry and replace that with an “Administer page” menu entry, see http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration . Ask for Admin rights to be able to go to the admin UI. * When on a non-terminal page (i.e. a WebHome page), go to the “Space” Admin UI when clicking  “Administer page”  * When on a terminal page, go to the Page Admin UI (http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration) when clicking  “Administer page” * Add a, xobject listener (or some other way) to prevent users without admin rights to be able to add a Rights XObject Note that one use case that would be nice to support is the following: * You create a page A * Some other persons create pages B, C, having your page A as parent * You change the permissions on page A to allow only yourself to view it (or edit it) * Suddenly people who had the rights to view or edit pages B and C don’t have them anymore. OTOH with my proposal above you wouldn’t be anymore to have private pages (unless you have Admin permissions). Is this acceptable? If not, do you have a counter proposal? Thanks -Vincent On 26 Jun 2015 at 13:44:29, vincent(a)massol.net (vincent(a)massol.net) wrote: I’ve spoken with Anca and here’s her opinion (barring any misunderstand from my part ;)): * She mentioned we should talk about Terminal Pages (i.e. no children) vs Non Terminal Pages, in term of terminology * Our UI must handle Terminal Pages as well as non Terminal Pages, i.e. we need to generify all our UIs to handle this. This is very important to Anca * The UI to create a new page should have an advanced option to be able to create a Terminal Page. She said she agree to link this feature to the Advanced User profile (for now, maybe it would be interesting to have it as an option like “hidden documents” later on). * She said we should provide a script to let users transform their existing pages from A/B into A/B/WebHome  * She said we probably don’t need to work on a script to convert parent/child relationship into Nested Documents since this change could cause existing apps to not work properly and for her this is an action that has be done manually on a per wiki basis depending on the usage, etc. * She said from her POV the Parent/child relationship is not used much by users on projects she’s been on and she’s seen this used by her or other devs when building apps and that these app will just have to be modified * She said we should be careful to not change the structure of current apps in XE for the moment since that could break some extensions/bookmarks. Personally I believe we shouldn’t relocate pages in the 7.x timeframe and when we do so (in 8.x probably) we should probably think about implementing aliases before to handle the move. * She agrees we should move the breadcrumb/index tree/etc to use Nested Documents and not be based on the parent/child anymore. She agrees having an option to put it back on if needed is good enough. However the field in the DB should stay for now. To sum up: Q0: +1 Q1, Q1.1, Q1.1.1: +1 with the proviso of having a UI that displays as well Terminal pages from non Terminal pages Q1.2: +1 provided we can create terminal pages from the UI Q2.1: +1 (but keep the parent field in the DB) Q2.1.1: -1 Q2.1.2: +1 Q2.2: -0 Q2.2.1: -0 (not really needed in her opinion) @Anca: please correct me if I’ve wrongly expressed what we discussed ;) Thanks -Vincent On 25 Jun 2015 at 15:16:57, Eduard Moraru (enygma2002(a)gmail.com) wrote: Hi, On Thu, Jun 25, 2015 at 11:59 AM, vincent(a)massol.net <vincent(a)massol.net> wrote: I`ve asked that same question 1 week ago [1] but put it more in the light of a security issue, since one could perform a denial-of-service-like attack or a phishing-like attack on a ND by "masking" it with a simple document that would high-jack existing URLs. Also, don`t forget that if for a user we can make the difference unnoticeable, for devs it will make life harder, since they need to query for 2 types of documents in their code. DB queries are even more sensitive to this, when, for example, you want to get all the immediate children of a document. They can be simple documents (documents in the space defined by the) or ND (WebHomes of subspaces), not o mention the issues of manipulating the space (path string) in order to get obtain this information. Thanks, Eduard [1] http://xwiki.475771.n2.nabble.com/Proposal-Introduce-the-notion-of-Nested-D…