Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Dynamic Shared By for Group Tasks
AmyRush
I'm hunting for a mechanisim to make the Shared by id's in the group task more dynamic. Has anyone done anything cool with group tasks?
Find more posts tagged with
Comments
Migrateduser
Generally with a CGITask or ExternalTask you add and remove groups and users associated with another task using the command line tools iwaddtaskgroup, iwaddtaskuser, iwrmtaskgroup and iwrmtaskuser. There are probably OpenAPI equivalents if you are using JSP/Java, but then you either need a session ID (available to CGITask) or to specify a username and password in your code (which may not be a great solution if you are using ExternalTask).
You first have to determine the ID of the task to change properties of, which you can do with iwgettaskbyname (somehow the code that changes the users/groups has to know the name of the task that was created by the workflow). This won't work if someone changes the name of the task for which you want to alter users/groups, which they can do through the GUI if they have some level of control (I haven't figured out how to disable this), so when the job is created you might want to log somewhere (maybe a job variable) the ID of the task that needs to be altered later.
Be aware of how this affects the tasks that send email notification regarding the task you are changing the sharedby for. If you use command line parameters in the ExternalTask to tell the email process which users/groups to send email to, I am not aware of any way to change the v attribute of the command element in workflow XML (to change the command line parameters to the new users/groups), so this may not work for you (it's a bad idea anyway). If you use task variables to control who the email goes to you would have to update those variables (which may mean logging the IDs of the tasks that send email as well as the tasks that you are changing ownership of). Best is to have the email process parse the XML of the task it is sending notification about for groups and users and send email to them.
Ninerfan
John,
I have a question that I think is related to this thread.
I would like to use a group in the <sharedby> element that is not part of a Solaris group. In this example the group "fans" would be just a text file somewhere with a list of members. Is this possible to do? Any pointers on how to approach this? Format on the new group file? I'm on Solaris 2.8 with TS 5.5.2 SP3
<sharedby>
<group v = "fans"/>
</sharedby>
Thanks in advance for any pointers.
JonathonG
Well, I'm not John, but I'll answer...
You would need to create code in your wft that read the file and expanded it into multiple <user> elements. The <group> element expects an OS group
HIH,
Jonathon
Independent Interwoven Contractor
Ninerfan
Perfect.
Thanks.
Sorry for the name screw up. ;-)
Migrateduser
First you have to confirm that the type of task you want to share supports <sharedby> - CGITask, UserTask, DummyTask, Submit/ConflictResolutionTask and maybe some others don't support sharedby (at least up to 5.5.x).
Next, I don't think there is anything you can put in the <sharedby> in job XML that will cause TeamSite to apply settings from your custom config file. I think what you would need to do is have your .wft look up the group in your custom config file and create a <user> element inside the <sharedby> for each user contained in that group in the config file. If your groups change a lot I would suggest adding a task variable to each task that indicates the identifier of the group in the custom config file - then you could periodically (or as part of an externaltask) run a process that resets all users associated with all tasks that are configured with this task variable - first remove all, then add all based on the current value of the specified custom group. There could be a performance imapct associated with this approach.
Another consideration is ExternalTasks that send email - I think by default the command line is set up at job creation time and the users/email addresses are passed as a parameter (I don't know for sure, I almost never use the default stuff). A better way would be to use a task variable containing the group name(s) to send email to associated with this externaltask and have the email script parse the users/email addresses based on that value. Or the email task could determine which task it is activating when it completes and use the sharedby associated with that task to figure out who to send email to.
I guess I would ask why you would want to go through this trouble (even though it's not really that complicated) instead of just using the OS groups. Even if you are pulling lists of members from SAP workcenters or whatever, it is typically easier to have something that extracts from that system to create OS groups than configuring <sharedby> using a custom config file like this. It definitely works though - I've done it. If you don't like maintaining /etc/groups by hand, you could have a process that parses a custom config file and sets up OS groups from it. or are you concerned about the 16-group NFS limit? I thought that only applied to file permissions, not to workflow. If that is your concern I would suggest considering the map_secondary_to_primary_gid (or whatever) setting in iw.cfg. You should probably only consider the custom config file approach if you don't have root permission (to alter the OS groups) or if the 16-group limit applies to workflows as well as file permissions and you are concerned about the potential side-effects of this change to iw.cfg. or if there's something I'm totally missing...
Ninerfan
Yes you are correct the reason I can't use the OS /etc/group file is because of the 16-group NFS limit. It's a long sad story but suffice to say we have a large number of groups in our implementation. This forces some power users to exceed their limit of 16. A lot of pain and strange workflow behavior could be remedied if we could separate the workflow groups from the file system groups. I will probably go down this road of reading a custom group file and creating <user> elements in the <shardby> element. I'll look around first on the devnet for the map_secondary_to_primary_gid solution and see if that has been working for people. I don't understand exactly what it's doing so I'm hesitant to use it.
Migrateduser
We've been forced to turn on the map_secondary_to_primary_gid flag in order to support the dozens of Solaris groups we need to support for TeamSite. It seems to work - meaning people are able to do what they need to do. What we hate about it is the byproduct of when you view backing store files via the Unix shell. It's annoying as **** to view the group owner of files in the backing store - it always shows your own primary group as the owner of every file. So the only way to see the true owner of any file/directory is to look at its File Properties in TeamSite. So far that seems to be the only drawback.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Johnny
The OS 16 group limit is only related to file/directory perms.
You can still use a high range set of OS groups that are purely for workflow process.
Your query methods should return users/groups from the high range (high range meaning a set of groups who's GID is higher than the range used for file/directory permisions. That way the file/directory perms will be used first when the OS retrieves file information, keeping them under the 16 group limit)
John Cuiuli
Adam Stoller
As I recall, he map_secondary_to_primary imposes performance overhead on TeamSite too - as it has to do this mapping for various operations. If at all possible - avoid using it.
Another alternative (that IT folks don't tend to like) is to provide those users who need to be in more than 16 groups with multiple accounts/userids - and thus split up the groups for that user to something less than 16. This of course can be confusing and annoying for the user (who has to remember which userid to login with to interact with files in which branch) - but hopefully the number of people who fall into this category is relatively small and composed of people who can comprehend the issue and grin-and-bear-it.
Also, in case people get the wrong idea - the 16 group thing is an NFS limitation not an Interwoven limitation. The map_secondary_to_primary is an Interwoven invention to work-around the NFS limitation.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Johnny
Still defending IWOV even on the outside. Such an admirable man!
John Cuiuli
NathanW
We do a similar thing to this at DOTARS - our WFT files read the OS groups, the TeamSite roles and a config file which sets out what I would call workflow roles - it dynamically determines who can do what - approve content for example and then inserts a <user> block for each person. This enables us to do things dynamically like exclude the content creator from being the approver of content without having to have OS groups all over the place. Works really well.
Nathan Wall
Department of Transport and Regional Services (Australia)
JonathonG
Interestingly enough, my current project is on Windows, which doesn't have the 16 group limitation (one of the very few advantages). However, we are still using the custom file route for group definitions. This has to do with the shared nature of the TeamSite server (amongst about 5-6 different project groups) and the high (bureaucratic) overhead associated with getting OS groups created.
BTW, earlier when I said I wasn't John, I wasn't talking about a name mix-up, I'm just a different person than "John" who this question was originally addressed to.
Jonathon
Independent Interwoven Contractor