27 Jan
2011
27 Jan
'11
12:52 a.m.
I agree with this. I mean I like it as an approach that fixes an issue
in a relatively harmless way (1 + 2).
PR is really PITA, and this is known by any developer that had to send a
mail to another developer or to an administrator of their wiki with the
list of pages that should be saved with programming rights (list which
he has maintained on his desk on a pink post-it for 2 weeks or so,
adding or removing items on it whenever he did a change). Post-its are
so last century.
I might like the idea of signed scripts but I cannot see it through
right now (don't really understand fully what it means), for various
possible reasons. Which makes me think that if I need explanation on it
now, I might need some after it's implemented and I really think we
should make the app dev environment as accessible as possible to
"normal" people.
There are a couple of solutions for the fact that this solution is a
"patch" and not a real solution:
1/ we don't advertise the solution as an API, we advertise it as subject
to change (because we want to build it right) so if people are not
willing to maintain it on upgrades, they should stick to the current
solution which is having no solution
2/ we implement it as an application (it doesn't need more than a .xar,
right jerome?) on extensions.xwiki.org and who needs it takes it from
there and uses it in his development environment
As for objects vs doc metadata, yes, doc metadata would be nice, but
only _needed_ if we need to make a fast query (without a join to
xobjects & props tables), in my view. Which is not the case if I
understand correctly how this metadata will be used. Additionally, it
would make impossible the 2/ implementation above, it would be too "core".
Thanks,
Anca
On 01/19/2011 08:04 PM, Jerome Velociter 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 :)
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.
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.
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