topic Re: [Solved] Problem : Create a new role in Alfresco Archive

[Solved] Problem : Create a new role

emmanuel — Thu, 08 Jun 2006 09:11:17 GMT

Hi everybody,I'm working on the alfresco project for my company, and it seems to be very powerful. But, however , I got some trouble … Let me explain:I want to have a workflow (not very difficult, for this step :wink: )So I have 3 folders: => "Drafts => "Pending approval" => "Published"

Re: [Solved] Problem : Create a new role

rivetlogic — Thu, 08 Jun 2006 12:54:25 GMT

Hi,

If I understand what you're trying to do correctly, then you don't really need to create a new role.

Your Writers have access to the Drafts folder and they edit documents there. When they're done they request approval upon which the document is copied to the Pending Approval folder. You don't want the Writers to even see the Pending Approval folder. But you would like for the Approvers to see it.

Before I tell you how to do that, keep in mind that by default space permissions are inherited from the parent. And also, by default there is a group called EVERYONE that has Consumer (read-only) access to Company Home.

So, to disallow Writers from seeing the Pending Approvals folder, you need to:

- Login as admin
- Browse to Pending Approvals folder
- Go to Manage Space Users
- Uncheck Inherit Parent Space Permissions
- Invite users/groups to that folder in the way you want them to see it
- Make sure that you don't invite Writers

Hope this helps.

–Aladdin

Re: [Solved] Problem : Create a new role

emmanuel — Thu, 08 Jun 2006 13:44:39 GMT

I agree with your point of view.

But When a user has not right for reading, he can't write in a folder.

So if my writers request for an approval, I want to move my file in the "Pending approval" folder. And actually, I can't… With your solution, i can't send my file to the approval folder.

I draw what i want:

1) Writer A writes doc1.

2) Writer A wants an approval of doc1.

3) I create a "simple workflow rule" => move doc1 in pending approval folder

4) Writer A applies the rule, doc1 is in the pending folder. Writer A doesn't see it.

5) Approver B see the file in the pending folder, and can validate or reject it.

Actually, I got a problem in the (3) I have the error " permission denied, work didn't commit", you dont have the right to write in this folder.

That's strange…

Another idea?

Re: [Solved] Problem : Create a new role

rivetlogic — Thu, 08 Jun 2006 17:24:45 GMT

Sorry, my apologies. You're right, to do that you need write and no-read access to the Pending Approval folder.

You will need to create a new role let's call it Writer.

In permissionDefinitions.xml you need to do the following:

<!– ============================================= –>
<!– Convenient groupings of low level permissions –>
<!– ============================================= –>
      
      …
      <permissionGroup name="CreateNodes" expose="true" allowFullControl="false" />‍‍‍‍‍‍

<!– The permission to create new nodes                                            –>
      
      <permission name="CreateChildren" expose="true" >
         <grantedToGroup permissionGroup="AddChildren" />
         <!– Add this line –>
         <grantedToGroup permissionGroup="CreateNodes" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false" />
         –>
      </permission>‍‍‍‍‍‍‍‍‍‍

<!– Custom Role Begin –>
<!– A Writer can only create content     –>
   <permissionGroup name="Writer" allowFullControl="false" expose="true" >
     <includePermissionGroup type="sys:base" permissionGroup="CreateNodes" />
   </permissionGroup>
<!– Custom Role End –>‍‍‍‍‍‍

<permissionGroup name="Writer" extends="true" expose="true"/>‍

Invite Writers to the Pending Approval folder with the Writer role.

Hope this helps.

–Aladdin

Re: [Solved] Problem : Create a new role

emmanuel — Fri, 09 Jun 2006 06:55:11 GMT

thanks a lot for your help, i'll check that solution now!

I answer you if it works or not!

Re: [Solved] Problem : Create a new role

emmanuel — Fri, 09 Jun 2006 07:45:21 GMT

Hi,

First, thanks a lot to take care of my problem!

But it still doesn't work, i've done what you wrote, it was close of what I have done the first time. But it doesn't work…

I think we're close to the solution, but I can't see where the problem is!

If an alfresco engineer could help, it will be wonderful :wink:

Re: [Solved] Problem : Create a new role

rivetlogic — Fri, 09 Jun 2006 12:03:41 GMT

Hi,

I actually tried it and it works for me. How is it not working for you? What I do is:

- As admin I add a rule to the Drafts folder:

Pending Approval

Send for approval

- Invite Writers group to Pending Approval folder with Writer role that we defined earlier

- As a writer I upload a file into the Drafts folder

- Run Action: Send for approval

- The writer can't see the Pending Approval folder but the doc is copied into it

- I login as an Approver and I see the Pending Approval folder with the doc in it.

If these steps are different from what you do can you post the differences?

It would also help if you post your permissionDefinitions.xml file.

Thanks,

–Aladdin

Re: [Solved] Problem : Create a new role

emmanuel — Fri, 09 Jun 2006 12:52:25 GMT

Fine!

Thanks a lot it works!

I found the only difference between me and you: it's in the approval rule!

I explain, you've written Add simple workflow to copy doc, but I use the rule Add simple workflow to move doc. So I get the following error : Permission denied.

I tried your solution with your rule, indeed, it works! But you copy the file, and I wanted it to be moved, but it don't appeared to be possible right now!

I'll mail the administrator of the forum, to have a look at this conversation, I think it will improve the development of the future verson of alfresco!

Thanks a lot.

Hope a developper of the application could answer. :wink:

Re: [Solved] Problem : Create a new role

rivetlogic — Fri, 09 Jun 2006 13:13:07 GMT

Hi,

I tried moving the doc instead of copying it and it still works. I didn't have to change anything else. The roles are the same, and the simple workflow rule was changed to move the file instead of copy it.

I'm using Alfresco version 1.2.0 enterprise edition. I don't think you've hit an Alfresco bug. It's most probably something else.

Can you post your permissionDefinitions.xml file, or at least the relevant parts?

Cheers,

PS: If the copy worked but the move didn't, it seems that you do not have delete permissions on the Drafts folder.

–Aladdin

Re: [Solved] Problem : Create a new role

andy — Fri, 09 Jun 2006 13:48:16 GMT

Hi

It is possible to change the permissions required for move (and copy) in
config\alfresco\public-services-security-context.xml.

This would affect all moves.

If you want more control you could

1) Add an action that moves regardles of permissions
2) Use an action that can run as the person who created it
3) Add a new service and protect it and add an action for the service

I am not sure if option 2 is available in general.
It can be used for scheduled actions.

Regards

Andy

Re: [Solved] Problem : Create a new role

emmanuel — Fri, 09 Jun 2006 13:52:24 GMT

Whoa,

It's amazing!

Since I found the problem I decided to test it with the 1.3 version, and it works.

but i still got the problem with the 12.1 version.

Thanks a lot for your help, I can change the topic now!

Re: [Solved] Problem : Create a new role

iguasch — Thu, 29 Jun 2006 15:34:17 GMT

I have tested the Writer role following the instructions with Tomcat Alfresco 1.3.0. and I have detected a permission problem but only when a content rule is defined in the destination workflow folder.

The procedure test is the following:

OK case:

* A Draft folder exists with unchecked Inherit Parent Space Permissions and User1 with Coordinator role. A simple workflow rule is defined for all items to copy/move (both tested) to Pending approval for Inbound content.

* A Pending approval exists with unchecked Inherit Parent Space Permissions, User1 with Writer role and User2 with Coordinator role.

1.- User1 adds content to Draft folder
2.- User1 accepts approval step and content is copied/moved (both tested) to Pending approval correctly

NOK case:

* A Draft folder exists with unchecked Inherit Parent Space Permissions and User1 with Coordinator role. A simple workflow rule is defined for all items to copy/move (both tested) to Pending approval for Inbound content.

* A Pending approval exists with unchecked Inherit Parent Space Permissions, User1 with Writer role and User2 with Coordinator role. A content rule is created in this folder, don?t matter what, add aspect, simple workflow, add categorization, etc.

1.- User1 adds content to Draft folder
2.- User1 accepts approval step and a Permission Denied error is issued

After this, if you remove the Pending approval content rule all works correctly again.

Any idea ? Thank you.

Re: [Solved] Problem : Create a new role

iguasch — Thu, 29 Jun 2006 15:35:19 GMT

Re: [Solved] Problem : Create a new role

iguasch — Thu, 29 Jun 2006 15:36:25 GMT

Re: [Solved] Problem : Create a new role

iguasch — Thu, 29 Jun 2006 15:38:32 GMT

Re: [Solved] Problem : Create a new role

iguasch — Thu, 29 Jun 2006 15:40:52 GMT

I have tested the Writer role following the instructions with Tomcat Alfresco 1.3.0. and I have detected a permission problem but only when a content rule is defined in the destination workflow folder.

The procedure test is the following:

OK case:

* A Draft folder exists with unchecked Inherit Parent Space Permissions and User1 with Coordinator role. A simple workflow rule is defined for all items to copy/move (both tested) to Pending approval for Inbound content.

* A Pending approval exists with unchecked Inherit Parent Space Permissions, User1 with Writer role and User2 with Coordinator role.

1.- User1 adds content to Draft folder
2.- User1 accepts approval step and content is copied/moved (both tested) to Pending approval correctly

NOK case:

* A Draft folder exists with unchecked Inherit Parent Space Permissions and User1 with Coordinator role. A simple workflow rule is defined for all items to copy/move (both tested) to Pending approval for Inbound content.

* A Pending approval exists with unchecked Inherit Parent Space Permissions, User1 with Writer role and User2 with Coordinator role. A content rule is created in this folder, don?t matter what, add aspect, simple workflow, add categorization, etc.

1.- User1 adds content to Draft folder
2.- User1 accepts approval step and a Permission Denied error is issued

After this, if you remove the Pending approval content rule all works correctly again.

Any idea ? Thank you.

Re: [Solved] Problem : Create a new role

andy — Thu, 29 Jun 2006 16:27:32 GMT

Hi

Rules and actions are run as the person who invokes them.
If they do not have suitable permission to carry out the underlying operations then permission may not be allowed. Remember the owner of a node (by default the creator) has all permissions for the node.

Version 1.4 will be extending workflow and permissions.

Regards

Andy

Re: [Solved] Problem : Create a new role

csnell52 — Fri, 30 Jun 2006 09:59:13 GMT

On the same vain as theis discussion, I created a simple workflow that included an email notification on approval/rejection. Is there any way to email the document author (owner) rather than a selected group or user.

I am thinking that the draft folder will have documents written by many authors (writers) so I want to taylor the email to whomever it was that wrote the document in the first place not a group or just one user taken from the users list.

Re: [Solved] Problem : Create a new role

csnell52 — Fri, 30 Jun 2006 10:07:23 GMT

Can you tell me where in permissionDefinitions.xml each snippet of code fits. (The last two snippets)

I have tried a number of differnt places and still cant get this to work. I get this error in the log:

10:36:21,274 WARN [org.alfresco.web.app.ResourceBundleWrapper] Failed to find I18N message string key: Writer

<!– ============================================= –>
<!– Convenient groupings of low level permissions –>
<!– ============================================= –>
      
      …
      <permissionGroup name="CreateNodes" expose="true" allowFullControl="false" />‍‍‍‍‍‍

<!– The permission to create new nodes                                            –>
      
      <permission name="CreateChildren" expose="true" >
         <grantedToGroup permissionGroup="AddChildren" />
         <!– Add this line –>
         <grantedToGroup permissionGroup="CreateNodes" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false" />
         –>
      </permission>‍‍‍‍‍‍‍‍‍‍

<!– Custom Role Begin –>
<!– A Writer can only create content     –>
   <permissionGroup name="Writer" allowFullControl="false" expose="true" >
     <includePermissionGroup type="sys:base" permissionGroup="CreateNodes" />
   </permissionGroup>
<!– Custom Role End –>‍‍‍‍‍‍

<permissionGroup name="Writer" extends="true" expose="true"/>‍

Invite Writers to the Pending Approval folder with the Writer role.

Hope this helps.

–Aladdin

Re: [Solved] Problem : Create a new role

emmanuel — Fri, 30 Jun 2006 14:34:15 GMT

Hi,

I think the best way is to show you my permission-definition.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE permissions >
<!–PUBLIC '-//ALFRECSO//DTD PERMISSIONS//EN' 'permissionSchema.dtd' –>

<!– Note: the above is commented out as spring does not seem to find the dtd –>

<!– ============================================ –>
<!– The base permission model for the repository –>
<!– ============================================ –>

<!– The parent permission checks were removed 20/1/2006 –>

<permissions>

    <!– Namespaces used in type references –>

   <namespaces>
      <namespace uri="http://www.alfresco.org/model/system/1.0" prefix="sys"/>
      <namespace uri="http://www.alfresco.org/model/content/1.0" prefix="cm"/>
   </namespaces>

   <!–                                                                                   –>
   <!– Permission sets link permissions and groups of permissions to types and aspects   –>
   <!– defined in the model. Permissions defined against a type apply to all objects     –>
   <!– that inherit from that type. Permissions defined against aspects apply to all     –>
   <!– objects or only objects that have the aspect applied. For example, the permission –>
   <!– to lock an object could apply to any object but the permission to unlock an       –>
   <!– object woujld only apply to objects that have the lockable aspect.                –>
   <!–                                                                                   –>

   <!– =============================================== –>
   <!– Base permissions available on all types of node –>
   <!– =============================================== –>

   <permissionSet type="sys:base" expose="all" >

      <!– ================= –>
      <!– Permission groups –>
      <!– ================= –>

      <!–                                                                                –>
      <!– Permission groups are convenient groups of permissions. They may be used in    –>
      <!– thier own right or as the effective set of permissions. If an authority has    –>
      <!– all the permissions that make up a permission group they also have that        –>
      <!– permission group even though it has not been explicitly granted.               –>
      <!–                                                                                –>

      <!– =========== –>
      <!– Full access –>
      <!– =========== –>

      <!–                                                                                –>
      <!– By default this is exposed for all objects unless inherited objects choose to –>
      <!– expose only selected objects at the object level.                              –>
      <!–                                                                                –>

      <permissionGroup name="FullControl" expose="true" allowFullControl="true" />

      <!– ============================================= –>
      <!– Convenient groupings of low level permissions –>
      <!– ============================================= –>

      <permissionGroup name="Read" expose="true" allowFullControl="false" />
      <permissionGroup name="Write" expose="true" allowFullControl="false" />
      <permissionGroup name="Delete" expose="true" allowFullControl="false" />
      <permissionGroup name="AddChildren" expose="true" allowFullControl="false" />

      <!– =========== –>
      <!– Permissions –>
      <!– =========== –>

      <!– The permission to read properties on a node                                    –>
      <!–                                                                                –>
      <!– The properties of a node may ony be read if there is read access to the parent –>
      <!– node. ReadChildren access to the parent node is recursive for all nodes from   –>
      <!– which the node inherits permissions. Access is required down the permission    –>
      <!– tree at all pioints.                                                           –>
      <!–                                                                                –>

      <permission name="ReadProperties" expose="true" >
         <grantedToGroup permissionGroup="Read" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

      <!– The permission to read the children of a node                                 –>
      <!–                                                                               –>
      <!– This permission is recursive. It requires the same permission is granted to   –>
      <!– all of the parent nodes from which this node inherits permissions             –>
      <!–                                                                               –>

      <permission name="ReadChildren" expose="true" >
         <grantedToGroup permissionGroup="Read" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

      <!– The permission to write to the properties of a node                           –>
      <!–                                                                               –>
      <!– This permission includes adding aspects to a node as they are stored as       –>
      <!– a property.                                                                   –>
      <!–                                                                               –>

      <permission name="WriteProperties" expose="true" >
         <grantedToGroup permissionGroup="Write" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

      <!– The permission to delete a node                                               –>
      <!–                                                                               –>
      <!– A node can only be deleted if there is delete permission on the node, if the –>
      <!– node is accesible via its parent, and if the node can be deleted from its     –>
      <!– parent. Currently, there is no check that all the children can be deleted.    –>
      <!– This check can be added but requires more work so the UI is not checking this –>
      <!– permission just to show the delete icon.                                      –>
      <!–                                                                               –>

      <permission name="DeleteNode" expose="true" >
         <grantedToGroup permissionGroup="Delete" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         <requiredPermission on="parent" name="DeleteChildren" implies="false"/>
         <requiredPermission on="node" name="DeleteChildren" implies="false"/>
         –>
         <!– Remove the recursive check for now for performance –>
         <!– TODO: have one permission to check for delete on an item and one to check –>
         <!–       child permissions when delete is called on the node service          –>
         <!– <requiredPermission on="children" name="DeleteNode" implies="false"/>     –>
      </permission>


      <!– The permission to delete children of a node                                   –>
      <!–                                                                               –>
      <!– At the moment this includes both unlink and delete                            –>
      <!–                                                                               –>
      <permission name="DeleteChildren" expose="true" >
         <grantedToGroup permissionGroup="Delete" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

      <!– The permission to create new nodes                                            –>

      <permission name="CreateChildren" expose="true" >
         <grantedToGroup permissionGroup="AddChildren" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false" />
         –>
      </permission>

      <!– The permission to link nodes                                                  –>

      <permission name="LinkChildren" expose="true" >
         <grantedToGroup permissionGroup="AddChildren" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

     <!– The permission to delte associations between nodes (not children)              –>

      <permission name="DeleteAssociations" expose="true" >
        <!– Commented out parent permission check …
        <requiredPermission on="parent" name="ReadChildren" implies="false"/>
        –>
      </permission>

      <!– The permission to read associations                                           –>

      <permission name="ReadAssociations" expose="true" >
        <!– Commented out parent permission check …
        <requiredPermission on="parent" name="ReadChildren" implies="false" />
        –>
      </permission>

      <!– The permission to create associations                                         –>

      <permission name="CreateAssociations" expose="true" >
        <!– Commented out parent permission check …
        <requiredPermission on="parent" name="ReadChildren" implies="false" />
        –>
      </permission>

      <!– ==================================================== –>
      <!– Permissions related to the management of permissions –>
      <!– ==================================================== –>

      <!– The permission to read the permissions on a node                              –>

      <permission name="ReadPermissions" expose="true" >
        <!– Commented out parent permission check …
        <requiredPermission on="parent" name="ReadChildren" implies="false"/>
        –>
      </permission>

      <!– The permission to the change the permissions associated with a node           –>

      <permission name="ChangePermissions" expose="true" >
        <!– Commented out parent permission check …
        <requiredPermission on="parent" name="ReadChildren" implies="false"/>
        –>
      </permission>

   </permissionSet>

   <!– ================================================ –>
   <!– Permissions available to all content and folders –>
   <!– ================================================ –>

   <permissionSet type="cm:cmobject" expose="selected">

      <!– Kept for backward compatibility - the administrator permission has   –>
      <!– been removed to aviod confusion –>
      <permissionGroup name="Administrator" allowFullControl="true" expose="false" />

      <!– A coordinator can do anything to the object or its childeren unless the     –>
      <!– permissions are set not to inherit or permission is denied.                 –>
      <permissionGroup name="Coordinator" allowFullControl="true" expose="true" />

      <!– A collaborator can do anything that an editor and a contributor can do –>
      <permissionGroup name="Collaborator" allowFullControl="false" expose="true">
         <includePermissionGroup permissionGroup="Editor" type="cm:cmobject" />
         <includePermissionGroup permissionGroup="Contributor" type="cm:cmobject" />
      </permissionGroup>

      <!– A contributor can create content and then they have full permission on what –>
      <!– they have created - via the permissions assigned to the owner.              –>
      <permissionGroup name="Contributor" allowFullControl="false" expose="true" >
          <!– Contributor is a consumer who can add content, and then can modify via the –>
          <!– owner permissions.                                                      –>
          <includePermissionGroup permissionGroup="Consumer" type="cm:cmobject"/>
          <includePermissionGroup permissionGroup="AddChildren" type="sys:base"/>
          <!– Check out requires write permissions so this will not apply to all      –>
          <!– documents.                                                              –>
          <includePermissionGroup type="cm:lockable" permissionGroup="CheckOut"/>
      </permissionGroup>

      <!– An editor can read and write to the object; they can not create    –>
      <!– new nodes. They can cehck out content into a space to which they have       –>
      <!– create permission.                                                          –>
      <permissionGroup name="Editor" expose="true" allowFullControl="false" >
          <includePermissionGroup type="cm:cmobject" permissionGroup="Consumer"/>
          <includePermissionGroup type="sys:base" permissionGroup="Write"/>
          <includePermissionGroup type="cm:lockable" permissionGroup="CheckOut"/>
      </permissionGroup>

      <!– The Consumer permission allows read to everything by default.                  –>
      <permissionGroup name="Consumer" allowFullControl="false" expose="true" >
          <includePermissionGroup permissionGroup="Read" type="sys:base" />
      </permissionGroup>

   </permissionSet>

   <!– =============================== –>
   <!– Permissions specific to content –>
   <!– =============================== –>

   <permissionSet type="cm:content" expose="selected">

      <!– Extend some base permission groups to include permissoins related to content. –>
      <permissionGroup name="Read" extends="true" expose="false"/>
      <permissionGroup name="Write" extends="true" expose="false"/>

      <!– Add an execute permission group.                                              –>
      <permissionGroup name="Execute" allowFullControl="false" expose="false"/>

      <!– Content specific low-level permissions.                                       –>

      <!– The permission to read content.                                               –>

      <permission name="ReadContent" expose="false">
         <grantedToGroup permissionGroup="Read"/>
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

      <!– The permission to write content.                                              –>

      <permission name="WriteContent" expose="false">
         <grantedToGroup permissionGroup="Write" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

      <!– Execute permission on content.                                                –>

      <permission name="ExecuteContent" expose="false">
         <grantedToGroup permissionGroup="Execute" />
         <!– Commented out parent permission check …
         <requiredPermission on="parent" name="ReadChildren" implies="false"/>
         –>
      </permission>

      <permissionGroup name="Coordinator" extends="true" expose="true"/>
      <permissionGroup name="Collaborator" extends="true" expose="true"/>
      <permissionGroup name="Contributor" extends="true" expose="true"/>
      <permissionGroup name="Editor" extends="true" expose="true"/>
      <permissionGroup name="Consumer" extends="true" expose="true"/>

   </permissionSet>

   <!– ============================================== –>
   <!– Permissions associated with the Ownable aspect –>
   <!– ============================================== –>

   <permissionSet type="cmwnable" expose="selected">

      <!– Permission control to allow ownership of the node to be taken from others     –>
      <permissionGroup name="TakeOwnership" requiresType="false" expose="false"/>

      <!– The low level permission to control setting the owner of a node               –>
      <permission name="SetOwner" expose="false" requiresType="false">
        <grantedToGroup permissionGroup="TakeOwnership" />
        <!– require to be able to reach the node and set properties in the node         –>
        <!– Commented out parent permission check …
        <requiredPermission on="parent" name="ReadChildren" />
        –>
        <requiredPermission on="node" name="WriteProperties" />
      </permission>

   </permissionSet>


   <!– =================================================== –>
   <!– Permission related to lock, check out and check in. –>
   <!– =================================================== –>

   <permissionSet type="cm:lockable" expose="selected">

      <!– At the moment these permissions are hidden so they do not appear in the list –>
      <!– of permissions.                                                               –>

      <!– Check Out permission - exposed for all object types                           –>
      <permissionGroup name="CheckOut" requiresType="false" expose="false"/>

      <!– Check In permission - only exposed when the lockable aspect is present        –>
      <permissionGroup name="CheckIn" requiresType="true" expose="false"/>

      <!– Cancel Check Out permission - only exposed for the lockable aspect is present –>
      <permissionGroup name="CancelCheckOut" requiresType="true" expose="false"/>

      <!– Low level lock permission                                                     –>
      <permission name="Lock" requiresType="false" expose="false">
        <grantedToGroup permissionGroup="CheckOut" />
        <requiredPermission on="node" type="sys:base" name="Write"/>
      </permission>

      <!– Low level unlock permission                                                   –>
      <permission name="Unlock" requiresType="true" expose="false">
        <grantedToGroup permissionGroup="CheckIn" />
        <grantedToGroup permissionGroup="CancelCheckOut" />
      </permission>

   </permissionSet>

   <!– ================== –>
   <!– Global permissions –>
   <!– ================== –>

   <!–                                                                                  –>
   <!– Global permissions apply regardless of any particular node context.              –>
   <!– They can not be denied by the permissions set on any node.                       –>
   <!–                                                                                  –>

   <!– Admin can do anything to any ndoe                                                –>
   <globalPermission permission="FullControl" authority="ROLE_ADMINISTRATOR"/>

   <!– For now, owners can always see, find and manipulate their stuff                  –>
   <globalPermission permission="FullControl" authority="ROLE_OWNER"/>

   <!– Unlock is granted to the lock owner                                              –>
   <globalPermission permission="Unlock" authority="ROLE_LOCK_OWNER"/>

   <!– Check in is granted to the lock owner                                            –>
   <globalPermission permission="CheckIn" authority="ROLE_LOCK_OWNER"/>

   <!– Cancel check out is granted to the locak owner                                   –>
   <globalPermission permission="CancelCheckOut" authority="ROLE_LOCK_OWNER"/>

</permissions>

Hope this help!

I'm already interested by your solution of the notification …. If you find an issue I would like to know what you found!

Thanks