5 Aug
2011
5 Aug
'11
2:24 p.m.
Hi John,
On Thu, Aug 4, 2011 at 3:56 PM, Campbell, John <John.Campbell(a)viasat.com>wrote;wrote:
So this is something I would include in the Xwiki.ApprovalStatusSheet?
Yes.
Hi, Guillaume and Edo.
Thanks for the clarification, Edo. I'm pretty sure I understand the
concepts here now.
I have one document template that I'll be using for all of my process
documents, and I added the following line to the bottom of the template:
{{include document="XWiki.ApprovalStatusSheet"/}}
I have tested it, and it appears that each new document using that template
includes that element, so that takes care of my first question about being
able to attach the class to the template. :)
As for my other two questions, allow me to follow up a bit:
This can be set either by your script and/or by doing it manually through
the object editor.
Guillaume, I have gone into edit mode on the XWiki.ApprovalStatusClass, and
I see where I set the Values for the class, but I don't see where I can set
the default. Do you know of any examples you can point me to in the
documentation that might illustrate where I need to go and what I need to do
more thoroughly?
You can set a default value in the template document (since it's going to be
copied when creating a document that includes an object of your class).
2. Have the class default to the "in review"
value.
> 3. Make
this element invisible to the Users group, but visible and
> editable to the Supervisors group (for example, a Supervisor would be
able
> to review a page that is "in
review," and then if it is acceptable,
change
the
status to "approved").
This is something you can achieve in the sheet using the
$xwiki.isUserInGroup('XWiki.SomeGroup') API:
{{velocity}}
#if($context.user.isUserInGroup('XWiki.SomeGroup'))
your code goes here
#end
{{/velocity}} This is what is currently in that sheet:
{{velocity}}
#set($class = $doc.getObject('XWiki.ApprovalStatusClass').xWikiClass)
#foreach($prop in $class.properties)
; $prop.prettyName
: $doc.display($prop.getName())
#end
{{/velocity}}
You would need to replace the generic code with something like this:
{{velocity}}
#set($class = $doc.getObject('XWiki.ApprovalStatusClass').xWikiClass)
#if($context.user.isUserInGroup('XWiki.SomeGroup'))
Status: $doc.display('status')
#end
{{/velocity}}
It sounds like you're saying that the
$xwiki.isUserInGroup('XWiki.SomeGroup') API
will do a check to see if the
user is in the correct group, and if so, then the subsequent lines of code
will execute, making that field visible. Is my understanding correct? Is
there a way to make the ApprovalStatus class display as a drop-down box for
supervisors/admins?
This can be controlled from the Class -> you can define how a given property
should be displayed in the options for that property as available from the
class editor.
Guillaume
I'm sorry for all the questions, but I'd really like to be able to
demonstrate this functionality to my manager. I think
XWiki is ideal for
this project, but having this functionality is critical.
I sincerely appreciate all the help.
John
-----Original Message-----
From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On Behalf
Of Guillaume Lerouge
Sent: Thursday, August 04, 2011 7:09 AM
To: XWiki Users
Subject: Re: [xwiki-users] Approval process for user edits?
Hi John, Edo,
please see my replies below.
On Thu, Aug 4, 2011 at 2:09 PM, Edo Beutler <ebeutler(a)synventis.com>
wrote:
This can be set either by your script and/or by doing it manually through
the object editor.
able
document
Hi John,
Since we program such functionalities in Java components and not in
scripts I cant give you details on how to do it in Groovy, but I hope
I can explain Guillaume's idea of the script. I think his idea was the
following:
Register a listener to the save action. Doing this, your script /
method will always be called when a document gets saved.
When that happens you check for the saved document the field on your
ApprovalStatusClass and change the view rights on the document
accordingly if a change happened. So, if the reviewer checked a
document and changes the status to approved you change the view rights
of this document.
I hope this clarifies Guillaume's idea a bit ... and I understood the
idea correctly ;-)
Absolutely, that's exactly what I meant :-)
However, given that John is not a developer I'm afraid this solution is
going a bit tough for him to implement by himself.
Edo
On Wed, Aug 3, 2011 at 9:20 PM, Campbell, John <John.Campbell(a)viasat.com
wrote:
> Hi Guillaume,
>
> I understand some of the concepts to which you're referring, but I'm
more
of a writer/content guy, so my understanding of
the code/scripting is
very
limited. I'll try to follow along.
>
> I've created a class called ApprovalStatus and made it a static list
with
the following values: in
review|approved|rejected.
>
> I created the ApprovalStatusClass Sheet and ApprovalStatusClass
Template,
as well.
That's a good start :-)
Here are some things I would like to be able to
do with this class. Can
you tell me if these are feasible?
Yes, all 3 are feasible.
1. Attach the class to the process document
template I have already
created that users will use when they create new pages.
You'd need to write a script to find all such pages and automatically add
an
object of the right type to the pages. You can also do this manually using
the object editor.
2. Have
the class default to the "in review" value.
3. Make
this element invisible to the Users group, but visible and
editable to the
Supervisors group (for example, a Supervisor would be to review a page that is "in review,"
and then if it is acceptable,
change
the status to "approved").
This is something you can achieve in the sheet using the
$xwiki.isUserInGroup('XWiki.SomeGroup') API:
{{velocity}}
#if($context.user.isUserInGroup('XWiki.SomeGroup'))
your code goes here
#end
{{/velocity}}
I'm not sure I completely follow what
you're talking about with the
script
section of your comment. But I would love to
learn more. Can you
elaborate a
bit more, please?
Please see Edo's clarification above.
Hope this helps,
Guillaume
Thanks,
> John
>
> -----Original Message-----
> From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On
Behalf
Of Guillaume Lerouge
http://extensions.xwiki.org/xwiki/bin/view/Extension/Title+Post+Processing+…
Sent: Wednesday, August 03, 2011 2:55 AM
To: XWiki Users
Subject: Re: [xwiki-users] Approval process for user edits?
Hi John,
- Create a process class with a validation status ("under review",
"validated"...) [1]
- Create a groovy script that listens for changes of the value of the
status property and updates a XWikiRights object attached to the page
based
on the value of the validation status property
[2]
- -> when the status changes, the script will apply appropriate
rights
to the page
- -> you can list only "validated" on the homepage of one of your
Hope this helps,
Guillaume
[1] http://platform.xwiki.org/xwiki/bin/view/DevGuide/FAQTutorial
[2]
On Tue, Aug 2, 2011 at 8:07 PM, Dale Amon <amon(a)vnl.com> wrote:
> On Tue, Aug 02, 2011 at 05:45:09PM +0000, Campbell, John wrote:
> > Hello again, XWiki community.
> >
> > I am working on using XWiki to be the repository for a library of
process
> documents that will be added to and updated
on a constant basis by
members
> of our team. It looks like it's going to
be a great resource for us.
> >
> > However, I do have a question that involves rights and permissions.
Our
>> manager wants to incorporate an approval process in the process >> wiki. She wants users to be able to edit
existing process documents
and
>> create new process documents, but for
those documents to go through a
>> technical/style review by supervisors before they are published for
use
by
way
> the team. I don't see a way to manage
permissions/rights to make that
idea
> work for the wiki as a whole, though I can
see a workaround for new
process
>> documents (force them to be created in a "Review" space). Is there a
to
> make user edits go through a review process
before they can be
published/go
>> live?
>> >
>> > I realize that this goes against the basic concept of a wiki in some
>> ways, and I explained to our manager that we have version rollback
>> capability, but she wants these controls in place prior to publishing.
>> >
>> > Can anyone offer some guidance?