19 Nov
2015
19 Nov
'15
4:34 p.m.
I've posted 2 screenshots (mock-ups) corresponding to your proposal:
http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration#HPro…
2015-11-12 14:51 GMT+01:00 Eduard Moraru <enygma2002(a)gmail.com>om>:
On Thu, Nov 12, 2015 at 12:34 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
to
well.
Administration
the
so
regular
solution I
http://extensions.xwiki.org/xwiki/bin/download/Extension/Administration+App…
that
http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration#HImp…
isn't
page
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PageAdministration
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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 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 <enygma2002(a)gmail.com>om>:
> 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 > 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 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 > *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), 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 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 > 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]
On Wed, Nov 4, 2015 at 6:54 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> No more idea?
>
> 2015-11-02 16:35 GMT+01:00 Ecaterina Moraru (Valica) <
valicac(a)gmail.com
> >:
> >
> > > Regarding implementation, we need to consider how we will export > > page
> > > and preserve it's preferences.
> > >
> > > Thanks,
> > > Caty
> > >
> > > On Thu, Oct 29, 2015 at 1:57 PM, Guillaume "Louis-Marie"
Delhumeau
<
> > > gdelhumeau(a)xwiki.com> 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:
> >
> >
>
> > > >
> > > > 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 <
guillaume(a)xwiki.com
:
rollback
> > > > > problematic changes, but for the average admin this feature
> >
> > > 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 > >
exposed
> > > > well, event though it's quite useful.
> > > >
> > > > Food for thoughts,
> > > >
> > > > Guillaume
> > > >
> > > > On Fri, Aug 9, 2013 at 5:59 PM, Ecaterina Moraru (Valica) <
> > > > valicac(a)gmail.com
> > > > > 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, > > > > 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
> > > >
> > >
> >
>
> > > >
> > > > Thanks,
> > > > Caty
> > > > _______________________________________________
> > > > devs mailing list
> > > > devs(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> >
> >
> > --
> > Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs