Service subscribed by company does not show on new request form

[clampj]

Hi

 

We have a large org structure in SM.  We are using all the levels with nesting. So we have Company at the top level then below that division then below that department then costcentre then team.  The LDAP import pulls the team info AD so users are populated at the team level.

 

Some services have the entire company subscribed to it such as email and our HR system.  When viewing the "Assigned Users" (from the organisation view) for the company it is empty - it does not show the users contained within the nested groups.  Is this correct behaviour?  We can live with this if so however when it comes to raising a request, when prompted to select the service, the ones subscribed at the company level aren't showing.  From what I understand this is not correct behaviour - can someone confirm if this is a bug?

 

I've also created a test team directly under the company org and added myself to it.  I still cant see services subscribed at the company level when raising a request.

 

Any help greatly appreciated.

 

Thanks

J

[Victor]

@clampj

51 minutes ago, clampj said:

When viewing the "Assigned Users" (from the organisation view) for the company it is empty - it does not show the users contained within the nested groups.  Is this correct behaviour?

Assigned users only display if for the direct parent... so if you have users in a team and the team is the child of a department, for example, then you won't see the assigned users in department, you will see them only on the team... 

51 minutes ago, clampj said:

when it comes to raising a request, when prompted to select the service, the ones subscribed at the company level aren't showing.

I don't think it works like this... so from the above example, if you subscribe the department to the service, the users assigned to the child team won't be actually subscribed to the service... only users that are directly assigned to the department... so, what I mean, service subscription does not currently work with nested groups, it was not designed to do so.

[clampj]

Thanks for the reply Victor

Re the subscriptions, are you sure that is correct?  James Ainsworth posted this from another topic which suggests what we are trying to do should work:

"Thanks for your post. I will talk with development to see what options we have. Out of curiosity, at what level are you adding All users to in your organization structure? Moving forward the organizational structure will play a more and more important role with the different applications so for best results you will want to make sure you define your different organization levels and add the users to the lowest level which in most cases will be department.or team.An example of how this can be used is with the Service Subscriptions. When subscribing users you can subscribe the entire organization down to an individual. If you subscribe an entire organization it will include users in all of the sub groups as well. Having users in the departments then allows you to easily create services for a particular department while at the same time making them available to any services subscribed to the entire organization."

 

Can anyone from Hornbill confirm?

[Victor]

@clampj 

57 minutes ago, clampj said:

Re the subscriptions, are you sure that is correct? 

The SQL query that returns the services subscribed to the user (contact or co-worker) does not cater for nested groups. So, yes, it does not work with nested groups in current functionality.

57 minutes ago, clampj said:

James Ainsworth posted this from another topic which suggests what we are trying to do should work

What I think James meant is that moving forward (so in a future update) the functionality will be enhanced so when you subscribe an organisation to a service, all nested sub-groups to that organisation, down to the user will be subscribed to that service.

[clampj]

In that case the post is misleading as I read it as saying that org structure will become more important for the different apps in future.  He then goes on to advise to setup the org structure how we've done it but how we've done it doesn't work with the current functionality.

 

Do the nested groups serve any purpose at all at the moment?  If not they shouldn't be there until they are actually usable.  That way people wont spend hours setting up an Org structure that doesn't work.  We'll now have to spend more time re-working this so that its usable.

 

Any ideas how long this will take given the post I quoted is from May 2016!!!!

 

Any one from hornbill care to comment?

[Victor]

9 minutes ago, clampj said:

Any one from hornbill care to comment?

I just did ... but I'm afraid I can only advise on current functionality... I assume you would like more input from someone from development or product management teams...

[James Ainsworth]

Hi @clampj

Thanks for your post.  I can't recall the entire context of my earlier post, but at the time I may have assumed that for subscriptions there was some ability to inherit membership from other groups.  My recommendations on building your organisation structure early on was also to ease any restructuring of the org structure later on, which might be used by future apps.

We do have a change in the backlog to look at the inheritance of group membership for subscriptions on which I have added you to as an interested connection.  I'll discuss with our dev teams how this might be achieved.   This change is not currently scheduled, but I will update this post as the change progresses.

Regards,

James

[clampj]

@Victor - Apologies - I wasn't aware you were staff.

 

@James Ainsworth Thanks for adding me tot he change request.

 

Out of interest - does the nesting or orgs serve any purpose at the moment?

[James Ainsworth]

Hi @clampj

I don't believe that the nesting of your organisation structure has any specific purpose from a technical or automation perspective at the moment.  My past recommendation for building your structure from the start is more to support any future functionality that takes advantage of this hierarchy.  You may notice that the ability to select a "Parent'' can only be done on creation of a team, department, cost center, or any other group.  So, the creation of an organisation hierarchy from the start will make managing this in the future, much easier.

Regards,

James

[James Ainsworth]

As of Service Manager build 1480 we have provided a new features that allows for cascading subscriptions based on the Organisation structure.  The setting com.hornbill.servicemanager.services.subscriptions.allowSubgroupsInclusion has been added which will allow you to enable this ability.  Before changing this setting, you may want to review your current Organization Structure within Administration.  Once your structure has been defined and this setting has been enabled, you can set any of the Group subscriptions to include any groups that sit under the selected group as part of the subscription.

This will help reduce the number of groups that need to be added to a subscription, and it will also allow the Organisation structure to be arranged more appropriately, with the users listed within their appropriate groups.

Hope this helps.

Regards,

James