allowed elements in datacapture.cfg and custom_instantiation.cfg

Posted: 2 September 2009 in allowed, Custom instantiation, Data Capture Template, formAPI, FormsPublisher, Groups, Roles, Security, Teamsite, Users, Worfklow models, Workflows

The allowed element inside text, textarea, select, radio, checkbox, readonly and hidden works fine on datacapture forms within forms publisher. Whenever a workflow instantiation form uses the allowed element, it’s not using it to use the instance designed by it.

<item pathid=”somepath” name=”somepath”>
<text>
<allowed><cred role=”master” /></allowed>
</text>
<readonly />
</item>

This snippet of XML should have allowed masters to edit the field and anyone else would just be able to look at it without modifying it. Though this works fine in forms publisher, the workflow engine’s rendition does not concern itself with such authorisation.

Instead, formAPI has to be used. To find out the current user’s name, group and roles, we can use the IWDatacapture’s getUser(), getGroups() and getRoles() methods and show or hide the fields as we please.

getUser() returns the short username (not “Laurent Picquet” but “lpiquet”), getGroups() returns an array of group names the current user belongs to and getRoles() returns an array of roles the current user has in the the current branch (“admin,master” in my case).

var roles = IWDatacapture.getRoles();
 var isMaster=false;
 for (var i in roles){
 if (roles[i]=='master'){
 isMaster=true;
 }
 }
 prompt("isMaster",isMaster);
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s