Skip to main content

Hi All,

 

Can anyone outline what the rules for using newly created groups within a workflow especially in respect to user membership?

 

We have a custom SQL user manager installed that allows specific users to create "secure groups" for the organisational units they're responsible for and allocate users to these as they wish. This should allow them to restrict tasks that they have access to by replacing the standard destination group with one of these newly created "secure groups" via the workflow's activity destinations.

 

The groups don't change very frequently but we'd like the workflow task allocation to react in real time if it is restricted to a custom group. 

 

From testing we can see that the group creation (in the SQL schema) appears correct and that the task has been re-assigned to the new group but the task doesn't appear available to the group members via their worklist.  I suspect it's because it's not been resolved and cached possibly???

 

Similar groups created earlier function correctly and are visible so I belive the custom user manager is functioning correctly, however, the lack of an up to date,  single, clear, comprehensive or authoritive document surrounding building these on BlackPearl or K2 Five could mean that something small but important has been missed.

 

If I expire the identity table and restart the k2 Server Host everything is resolved immediately and the missing tasks become available so it looks like a newly created group needs to wait for caching before tasks are allocated to the memebrs correctly? Is this correct and if so is there any way to force the new group to be cached immediately via an API call or such?

 

I understand an alternative option is to use a smart object to resolve the users to allocate the task at the point of event execution but we were hoping to benifit from K2's group membership resolution functionality - i.e. when a user is added into a group, the system periodically resolves the mebership and any tasks allocated are made available to the new members - We see this as a big benefit that we'd ideally like to not loose.

 

Cheers in advance for any pointers...

 

Paul.

A follow up to my earlier post - after leaving a test to sit over night and wait for the periodic caching to kick in, we've confirmed that the newly created group and it's membership is indeed resolving correctly with the test workflow item being correctly allocated to the restricted group of users which is good. 

 

The problem that remains is, if a group is created and allocated to a task, it is a really bad user experience to then make the task unavailable until the next cache refersh kicks in.

 

Does anyone know if we can force the new group to be resolved on creation via an API call or some other supported means?

 

Thanks,

 

Paul.

You can use the force identity refresh tool


 


http://community.k2.com/t5/General-K2-Utilities/Force-Identity-Service-Refresh/ba-p/74061


 


HTH


Vernon

Thanks for joining the conversation Vernon but unfortunately the Force Identity Service Refresh tool doesn't quite provide what we need in this case. 

 

If it was a "one off" operation it would be perfect, but to provide a great user experience we need to be able to force the refresh of the identity cache on group creation, or better still have the group added to the cache on creation (rather than refreshing the whole cache).  This would all be triggered by an end user operation rather than by a user in a devops type role.

 

From what I understand the tool needs to be ran manually so this excludes calling it from via a SmartObject automatically?

 

Would it be possible for you to share the source for it (or a few pointers regarding the API calls that it makes) as this may allow the creation of a WCF service that could could be callable via a SmartObject? This would allow it all to be automated and a seamless near-realtime (great) user experience.

 

If this is possible I'd happily add the service code back to the Blackmarket for others to benefit from if this helps share the knowledge...

 

Thanks,

 

Paul.

Just to complete this thread, we've managed to trigger a new group's resolution immediately following it's creation.

 

I'm sure the following isn't supported by K2 so pleae be aware of this and I've only tested this on Blackpearl 4.7 so it may not work on any other version.

 

Utilizing the following code within a WCF services allows us to hook this isto a SmartForm event via a smart object so that once the end user creates the new security group the application can Kick K2 into resolving the identity allowing the task to mear instantly appear on the appropriate user's worklists.

 

This avoiods the need for waiting for a periodic referesh to occur.

 

Once again though to re-iterate - I doubt this will be supported by K2 and may not work across versions (major, minor or patch updates)

 

using SourceCode.Security.UserRoleManager.Management;
using SourceCode.Hosting.Server.Interfaces;

namespace ProcessTrack.K2.Services.UserManager
{
    public static class Cache
    {
        static public void GroupRefresh(string Fqn, string K2ConnectionString)
        {
            UserRoleManager userRoleManager = new UserRoleManager();

            userRoleManager.CreateConnection();
            userRoleManager.Connection.Open(K2ConnectionString);

            FQName fQName = new FQName(Fqn);

            IdentityType identityType = IdentityType.Group;

            IdentitySection identitySection =
                IdentitySection.Identity |
                IdentitySection.Containers |
                IdentitySection.Members;

            userRoleManager.ResolveIdentity(fQName, identityType, identitySection);

            userRoleManager.Connection.Close();
        }
    }
}

 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings