On 27 Jun 2015 at 10:29:00, [email protected] ([email protected](mailto:[email protected])) wrote:
> On 26 Jun 2015 at 18:26:11, [email protected] > ([email protected](mailto:[email protected])) wrote: > > > 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? > > A counter proposal would be to introduce a Permissions to control > Permissions. This is probably what would be the more flexible and would allow > for all use cases. We would still need to decide if we want to use the page level permission or the space level one when on a non-terminal page. Ideally it should be the space level UI IMO since it has more features (hence my initial proposal above). However, since we may want to retain the ability for a user to edit permissions, we could allow users with the “Permission” permission to go to that Admin page but only be able to modify permissions while requiring Admin permissions to modify the other options of that page. WDYT? Thanks -Vincent > > > Thanks > -Vincent > > > Thanks > > -Vincent > > > > > > > > > > On 26 Jun 2015 at 13:44:29, [email protected] > > ([email protected](mailto:[email protected])) 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 > > > ([email protected](mailto:[email protected])) wrote: > > > > > > > Hi, > > > > > > > > On Thu, Jun 25, 2015 at 11:59 AM, [email protected] > > > > wrote: > > > > > > > > > Hi Marius and all, > > > > > > > > > > On 25 Jun 2015 at 08:19:22, Marius Dumitru Florea ( > > > > > [email protected](mailto:[email protected])) > > > > > > > > > > wrote: > > > > > > > > > > [snip] > > > > > > > > > > > >> Q1. **NS vs ND in the UI** > > > > > > >> > > > > > > > > > > > > > >> Q1.1 The majority agreed that since the final purpose are ND, we > > > > > > >> > > > > > should > > > > > > >> display ND in the UI, since it simplifies the mental model of > > > > > > >> the > > > > > user. > > > > > > >> This implies removing the Space concept from the UI. > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > >> Q1.1.1 A consequence is hiding the 'WebHome' name in the UI. > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > >> > > > > > > >> Q1.2 Although the default should be ND, the question is if we > > > > > > >> want to > > > > > give > > > > > > >> the option to display NS in the UI. This would be implemented as > > > > > > >> an > > > > > > >> advanced and technical option. The main problem is that we might > > > > > > >> need > > > > > to > > > > > > >> provide UI alternatives for several components (menus, create > > > > > > >> step, > > > > > etc.) > > > > > > > > > > > > > > > > > > > > There are 2 questions actually: > > > > > > > A) Do we want to support creating non-WebHome documents from the > > > > > > > UI? > > > > > > > > > > Since we can have extensions or scripts/code that create non-WebHome > > > > > documents, I think it would be interesting to have the ability to do > > > > > so in > > > > > the UI but only for advanced users. > > > > > > > > > > I think I’d be in favor of doing the following: > > > > > > > > > > * When the user is an advanced user, in the Add > Page UI, have a > > > > > checkbox > > > > > entitled something like “Create a page without children” and when the > > > > > user > > > > > selects it and save, a document with the name entered will be created > > > > > > > > > > instead of a space and a WebHome. > > > > > > > > > > > > B) Do we display differently the WebHome documents from the > > > > > > > non-WebHome documents in the UI? > > > > > > > > > > I don’t think we need to display them differently, except maybe to > > > > > show > > > > > that one has children while the other doesn’t have children (terminal > > > > > leaf > > > > > vs node). > > > > > > > > > > > No comments on these questions? There are two important use cases: > > > > > > > > > > > > * a wiki that has custom code (Velocity/Groovy) in (non-WebHome) > > > > > > wiki > > > > > > pages is upgraded to 7.2+ (with nested documents) > > > > > > * an admin installs an extension with non-WebHome pages in XWiki > > > > > > 7.2+ > > > > > > (with nested documents) > > > > > > > > > > > > In both cases we cannot migrate the non-WebHome pages because it > > > > > > will > > > > > > break the code. So they have to stay. Do we show these pages in the > > > > > > > > > > > > document index (livetable / tree)? > > > > > > > > > > Yes > > > > > > > > > > > Note that these are not necessarily > > > > > > technical (hidden) pages. They can be data pages created/managed by > > > > > > an > > > > > > application/extension (whose code expects non-WebHome documents). > > > > > > Do > > > > > > we display them differently than the WebHome (nested) documents? > > > > > > > > > > I don’t think we need to display them differently. The only main > > > > > place > > > > > where we need to show a difference IMO is in the Add Page UI: when a > > > > > user > > > > > wants to create a new page under a non-WebHome document, we simply > > > > > display > > > > > a warning saying that this page is a special page that cannot have > > > > > children. > > > > > > > > > > In other words in the documentation we say that there are 2 types of > > > > > pages > > > > > in XWiki: > > > > > * Terminal pages which cannot have children. We can also explain how > > > > > these > > > > > came to be historically. > > > > > * Normal pages that can have children. > > > > > > > > > > > The > > > > > > users will ask why they can't add children to these (non-WebHome) > > > > > > pages. How do we explain this to non-technical users? > > > > > > > > > > Indeed, see above for an idea on how to handle this. > > > > > > > > > > > Moreover, since both WebHome and non-WebHome documents must > > > > > > coexist, > > > > > > what happens when one hides the other. E.g. an old application has > > > > > > created (through code) some data page AppData.SomePage; an user > > > > > > sees > > > > > > the "AppData" document (it's not a space anymore, it's actually > > > > > > AppData.WebHome) and adds a child (nested) document with the same > > > > > > name > > > > > > SomePage which actually creates AppData.SomePage.WebHome under the > > > > > > hood. > > > > > > > > > > Good point. We could add a check in the Add > Page UI to prevent > > > > > this. > > > > > > > > > > > Now what page does the user get when he loads the URL > > > > > > /bin/view/AppData/SomePage ? > > > > > > > > > > It’s up to us to decide but I guess the most logical is to get > > > > > AppData.SomePage since otherwise there would be no way to access it > > > > > from > > > > > the UI. > > > > > > > > > > > The WebHome or the non-WebHome > > > > > > (application) page? In any case, some users will not get the > > > > > > expected > > > > > > page. Moreover, which page should be indexed by Solr, the WebHome > > > > > > or > > > > > > the non-WebHome with the "same" name? If we index both then the > > > > > > users > > > > > > will complain they get "duplicate" results (with possible different > > > > > > > > > > > > highlights), and the result links will open the same document > > > > > > (which > > > > > > one we choose to make accessible, probably the WebHome one). > > > > > > > > > > I agree that we should add a check to prevent the creation of such > > > > > pages > > > > > from the UI. If it’s done by script then I don’t think we should > > > > > prevent it. > > > > > > > > > > > > > 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-Documents-td7594966.html#a7595203 > > > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > [snip] > > > > > > > > > > Thanks > > > > > -Vincent > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
