Hi, Everyone I am trying to incorporate security on feeds that are b

siddharthg521 over 11 years ago

Hi, Everyone

I am trying to incorporate security on feeds that are been posted to tempo.My objective is that only those users should be able to see the feeds on tempo that are been stored in process variable (pv!users) .If that process variable is updated and any user is removed or added than the users in that updated process variable must only see the feeds related to that process.(Removed users should no longer see the feeds and newly added users should see the respective feeds.)

When I am passing togroup(pv!users) to the viewers group of "Post feed to Tempo" Smart service, irrespective of who are the users present in the process variable, all users are able to see the feeds on tempo.

I have also tried to use "Tempo Audience Group" that is by default present in People Tab, and have passed in Viewers group of Smart service, but that will create a group for each instance of my process at root directory of Groups.

Hence, along with the abov...

Discussion posts and replies are publicly visible

Parents

0 Abhishek Shadangi
Appian Employee
over 11 years ago

@Sikhivahan As I already mentioned, it is not possible to refresh the Group Membership Cache in a SmartService plugin either.

@Siddharth I may have misinterpreted you group hierarchy, but I was explaining what you may do in-general. For your use case, you do not need to worry about "Tempo Audience Group" (TAG) what-so-ever. This group has a different purpose and is used ONLY for making the groups available in the Tempo UI (Message Tab) as target groups.

What I meant is to do the following: Create a Custom group (*NOT* as subgroup of TAG, but of some other predefined Custom group) -> Add members to this group -> Post to Tempo Event with this group as Viewers group. Now, by adding/removing users to/from this group, you can control the availability of the Tempo Event.

Having said so, please check your use case, do you really need so much control per Tempo Event? Consider -
1. Making the Tempo Event content better searchable, and train your users to use search if feasible,
2. Using predefined group hierarchy to control access/viewability instead of creating groups per instance. For instance, you can create N number of predefined groups, you may be able to target the posts based on certain rules, or you can do a combination of predefined and dynamic groups (if the predefined ones do not fit the rule criteria).

Would doing so work for you? Ideally, I would refrain from creating so many dynamic groups, just from the scalability point of view. But if you have no other choice (please explain in detail -- why?), and we can discuss approaches.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Abhishek Shadangi
Appian Employee
over 11 years ago

@Sikhivahan As I already mentioned, it is not possible to refresh the Group Membership Cache in a SmartService plugin either.

@Siddharth I may have misinterpreted you group hierarchy, but I was explaining what you may do in-general. For your use case, you do not need to worry about "Tempo Audience Group" (TAG) what-so-ever. This group has a different purpose and is used ONLY for making the groups available in the Tempo UI (Message Tab) as target groups.

What I meant is to do the following: Create a Custom group (*NOT* as subgroup of TAG, but of some other predefined Custom group) -> Add members to this group -> Post to Tempo Event with this group as Viewers group. Now, by adding/removing users to/from this group, you can control the availability of the Tempo Event.

Having said so, please check your use case, do you really need so much control per Tempo Event? Consider -
1. Making the Tempo Event content better searchable, and train your users to use search if feasible,
2. Using predefined group hierarchy to control access/viewability instead of creating groups per instance. For instance, you can create N number of predefined groups, you may be able to target the posts based on certain rules, or you can do a combination of predefined and dynamic groups (if the predefined ones do not fit the rule criteria).

Would doing so work for you? Ideally, I would refrain from creating so many dynamic groups, just from the scalability point of view. But if you have no other choice (please explain in detail -- why?), and we can discuss approaches.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data