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