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
long, that I do not understand why you are proposing a quick fix. In a farm,
issues starts with the initial template provided, which use XWiki.Admin 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.
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.
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.
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 ?
Sorry for these late comments (and please do not feel hurt by them ;) ), I
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