24 Jan
2011
24 Jan
'11
5:32 p.m.
On Mon, Jan 24, 2011 at 16:08, Jerome Velociter <jerome(a)xwiki.com> wrote:
On Mon, Jan 24, 2011 at 11:23 AM, Denis Gervalle
<dgl(a)softec.lu> wrote:
XWiki.Admin
This is only about contentAuthor (not author) of pages that require PR
rights.
I have never said that we should do so for ALL pages, just that the one that
PR.
xwiki:XWikiAdmin
Well, I could not disagree, but why should you explain PR in first place ?
1) I propose that initial and application XARs are properly built to put PR
Well, but this is the use case that cause most trouble in a farm currently.
On Mon, Jan 24, 2011 at 09:56, Jerome Velociter
<jerome(a)xwiki.com>
wrote:
> On Mon, Jan 24, 2011 at 9:38 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
> > On Wed, Jan 19, 2011 at 20:04, Jerome Velociter <jerome(a)xwiki.com>
> wrote:
> >
> >> Hi developers,
> >>
> >> I've setup and worked on a couple of wiki farms recently, and my
> feedback
> >> is
> >> that the PR issue has become for me a major PITA.
> >> It's worst than before, because we've introduced a lot of pages
that
> >> requires it : annotations style and script, plus the wiki macros for
> >> activity, tag cloud, space, etc. (OK, it's not really PR, it's edit
> right
> >> of
> >> the last person who did edit it, but it's the same issue mostly : you
> need
> >> to have it saved by someone with sufficient rights).
> >>
> >> Importing not as back-up (meaning all pages imported from the XAR are
> saved
> >> by the user doing the import) is not sufficient answer, for several
> reason
> >> :
> >> * User might not have programming rights
> >> * When user has programming rights, it's a BAD practice in terms of
> >> security
> >> (it means every page of the wiki initially has the PR right OK)
> >> * Wiki creation is also done by template wiki copy, which is not
covered
> by
> >> this
> >> * This problem is not just an import/creation problem, we need
generally
> a
> >> way to know which pages require PR, and which are missing this PR
(users
> >> can
> >> be deleted, their rights can change, etc.).
> >>
> >> OK, that looks like sufficient complaining :)
> >>
> >
> > All these issues were there in 1.x ! I am now working around them
since
so
Precisely because it is not an easy fix, and that I am not in favor of
increasing the complexity of this situation with an quick fix. ;)
>
> > In a farm,
> > issues starts with the initial template provided, which use long, that I do not understand why you are
proposing a quick fix.
Well, if you are working around them for so long, then I don't
understand why you've not proposed a patch before ;)
> in
> > place of xwiki:XWiki.Admin for the contentAuthor of pages requiring
PR.
> So,
> > it would be a good job to first fix that one for all, since this
breaks
things before you even started to edit them.
I don't think we want to do that.
In my opinion saving ALL pages with PR right is not the proper
solution. Its weak in terms of security right now, plus it only fixes
import, so that's not the root of the problem.
require PR should have a proper contentAuthor
that works for wikis in a
farm
like it works for standalone wikis.
>
> >
> >
> >> Here what I propose, tell me what you think :
> >>
> >> 1. We define a XWiki class, like XWiki.RequiredRightClass, with a
field
> >> that
> >> describe the required right the user saving the document must have
for
> it
> >> to
> >> behave properly (for example it will be "edit" for wiki macros
with a
> >> "wiki"
> >> scope, and "programming" for pages that uses privileged APIs, or
JSR
> >> scripts, or always use SSX, etc.)
> >> 2. We make a simple UI (for example in the administration section of
the
> >> admin app) that list all of them,
and their current status. Plus a
> button
> >> to
> >> fix the status if there is something to fix (a missing PR for
example)
> and
> >> if the user seeing the page has the required rights of course.
> >>
> >> That's what I propose for now.
> >>
> >
> > If you want to implement such UI, why not simply checking pages
against
> > their sources. Let say that you want to
check that you have not broken
> the
> > initial wiki import, you just have to provide the initial import XAR
> (fixed)
> > and see which page have lost (or gained) PR since this import. This
job
> > could be even better integrated in the
extension manager that could
check
> > installed extension has not been wrongly
tempered since installation.
> This
> > would not require any additional work on extension developer, this
could
> > even been retrofitted to the legacy
application manager for older
stuffs.
Again if you do that you consider all pages should be saved with PR
right (since there is no PR metadata in pages right now)
No, you can know from an import the pages that have initially receive PR.
These pages are those containing a contentAuthor having PR right on the
current wiki. If XAR are properly built, as I suggest above and probably
many farm admin had patch them, either in XAR or in their templates,
checking against such XAR should reveal which page had initially require
And that's just half of the problem again: you only fix import, but
you don't fix Admin user deleted, or programmer account deleted, etc.
Deleting Admin user is a very bad idea currently, since initial XAR use
them. Currently, I advice farms admins to use this single user to provide programming rights, unless they
really have an issue
sharing
access to this account.
There have been discussion on this list, by Vincent if I well remember,
of
using a 'system' user to avoid the issue
of changing or deleting the
Admin
account. This would be not so hard to introduce,
and I am sure this would
help a lot providing correct XARs.
>
> >
> >
> >>
> >> In the future, we could imagine that :
> >>
> >> 3. Programming right can only be granted on a page that requires
> >> it explicitly. This would be a non-backward compatible change.
> >>
> >> Let me know what you think.
> >>
> >
> > Even if I have been annoyed by PR issues in farm environment since
long,
> I
> > am almost -1 on your proposal, which seems to me increasing the
> complexity
> > of the issue, in place of fixing the root cause. One more UI for
admins
> to
> > take care about, one more thing to explain and understands for those
who
> > have never care about it, and are
probably the firsts to complains
that
> some
> > pages are not working properly. And on the developer side, one more
stuff
> to
> > take care about since there is no direct link between the requirement
and
> a
> > working page, so one more place for a potential bug. And obviously,
once
introduced, one more feature to maintain.
I definitely don't agree with this.
"one more thing to explain and understands " I'm very curious of how
you explain the programming right to your users/admin rights now.
"Well, ok, this page does not work, it misses programming rights. You
don't see it, but that's how it is, you have to take my word for it.
Look, now I save it with my Admin account and it just works!" Pure
magic ! At least a having UI that lists such pages and show their
status would help in making it understandable, and not make the
situation worst as you say.
This should works without having someone that
check it. Until you need to
extend it yourself, you should be able to use XWiki without knowing that
PR
exists.
Once you add a new admin panel, you will have to explain it that is all I
said.
>
> >
> > We really need to fix the real cause of PR issues, and I know how hard
it
> > could be, but it is clearly what we
need. IMHO, your proposal worsens
the
situation by amplifying the issue. Is this really the
best we can do
about
it ?
What do you propose then ?
where it is needed, even in a farm (using a
'system' user or
xwiki:XWiki.Admin at least)
2) Reduce the number of pages requiring PR, by providing non-PR interface
to
function that currently require them (isn't
it a goal in progress?)
3) Change the way to provide PR to a script (ie: signing them)
1) does not fix the problem. It only fixes your use case.
It does not handle :
* Local admins or editors saving pages that require PR right thus
breaking features (without even knowing it !)
* Programmers account deletion, or loss of PR
Those who have edit rights on these pages and use it, should already know
that they expose them to breakage, and these guys should not be many on a
given XWiki. This makes me think that we should also improve initial access
rights on the pages (I does that since so long that I have forgotten it)
2) I guess we all agree with that
nice :)
3) We are not there yet, as I said. Personally I will not have time
any time soon to get my hands on this, and this item has not been
planned on the roadmap. If you or someone else volunteer to tackle it
in releases not too far that would be just great.
I do not see good reason to suddenly want to tackle this issue with a quick
fix, while it was there since two major release already. I completely
understand your point here, since it expose the reasons why nothing have
been done. I would be more than happy if someone volunteer, I know Caled has
done a good job already looking at these issue, but AFAIK, he have concluded
that we should wait more before moving this forward.
In the meantime I don't agree with the vision where we hide our PR
problem under the carpet, and refuse to explain it
because we have
found a way to "almost live with it".
If PR are working out of the box, most user will never have to look at it,
but these users will surely found an additional complexity in your panel.
You may say that this point is minor. From my clients, major criticisms I
receive regarding XWiki is about its overall complexity for doing sometime
simple things. And most of them are in regards to access rights. We have had
long discussion with Cathy regarding a new interface for them, part of which
would better show PR on document. I would really prefer to see these put in
place but I know that it will require more time than your proposal.
Again, for me just fixing the import of XARs with PR
pages is not
satisfactory.
But we live with not fixed ones since so long, that it should be our first
steps before anything else IMHO.
We need to be able to detect quickly when a
feature/app/script is broken because it misses it's programming right,
for whatever reason it misses it.
If you really want that, this could be a extension that you may build on
comparing XAR with living applications. I agree that this could be a little
bit more trickier, but it have the double advantage of not adding new
meta-information and not being a core panel that impact all applications.
This addition of new informations without any guarantee that these
informations are reflecting the true reality of access rights, is for me
going in the wrong direction and increasing complexity of the issue. Once
your panel is in place, and it based its conclusion on possibly missing
informations (old page imported in a previous version), user will complains
even more. Using the contentAuthor field of initial XAR used for import to
provide the same panel is probably more reliable and backward compatible.
This leads to some questions:
1) What would be the interface of your panel ? (important to be careful on
clarity)
2) What would you present for pages that have PR and no meta information
saying it require it ?
3) What would you present for pages that haven't PR but meta information
requiring it ?
I hope you can reconsider your "almost veto".
So to resume what I dislike:
1) it adds a new admin panel that increase the overall complexity of XWiki,
could not it be optional ?
2) it require additional informations to deduce the needs of PR, which may
be absent in migrating XWikis, and could result in the reverse of what we
are trying to fix; but increasing the complexity of the issue.
I will not veto if no one else does but I would be happy the ear comments
from others on my comments.
Denis
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Denis
>
> Jerome.
>
> >
> > Sorry for these late comments (and please do not feel hurt by them ;)
),
I
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
have missed the initial thread.
Denis
>
> If we agree I volunteer to implement this in 3.0 M2.
>
> Jerome.
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
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