Visibility issue upon newly adding a user to a user group that has visibility to a thing

[vinesh]

Hello,

I am currently trying to implement a service which is executed by a User to move himself to a User Group that has Visibility permissions to a Thing. My Code is as below,

try {

   var groupName = "InstrumentUsers" ;
   var params_AddMember = {
      member: username,
      type: "User" /* STRING */
      };
   Groups[groupName].AddMember(params_AddMember);

}

//respond back with the result
result = {
   "success": "true",
   "Instrument": {
     "Alias": Things["Thing"].Alias,  //problem is in this line
     "GUID": "xyz"
  }
};

} catch (err) {
   result = { "success": "false" };
}

The "InstrumentUsers" does have the visibility to the "Thing". I also see that the user is properly moved inside the group. The problem arises when the user tries to execute the line Things["Thing"].Alias where he tries to read the property of the Thing. It says the user does not have visibility permission on the "Thing".

Surprisingly, upon executing the service second time, there is no error. I think the issue is that the Twx takes some time to give permission to a user even if he is the rightful group.

I tried pause(), executing some other service before reading the property etc. nothing works for me.

Regards,

Vinesh

[zyuan1]

Did you refresh the session after joining the User to the Group?

[vinesh]

I tried adding this line after adding the user to the user group as seen in another discussion thread.

var result = Resources["CurrentSessionInfo"].GetGlobalSessionValues().refresh;

This did not help me. Also, remember that I am trying to execute this service via REST call and not via mashup.

Please let me know if I can refresh the session in another way if possible.

[Constantine]

Hello,

I'm not sure why it works like this, it might be related to DB transactions scoping or some caching, dunno. In order to work around this situation you need to execute this code in two separate requests:

AddToGroup:

   var groupName = "InstrumentUsers" ;
   var params_AddMember = {
      member: username,
      type: "User" /* STRING */
      };
   Groups[groupName].AddMember(params_AddMember);

GetInstrument:

result = {
   "success": "true",
   "Instrument": {
     "Alias": Things["Thing"].Alias,  // problem is in this line
     "GUID": "xyz"
  }

Then chain them via ServiceInvokeCompleted in your mashup. I've just tried it, and it seems to work as expected, I don't get an error message anymore.

If you don't use it from the mashup, then the situation is slightly more complex, and in this case the only reasonable workaround that I know is using Async services.

Regards,
Constantine

[vinesh]

Thank you for the explanation. Ya, it is complicated as this service is called via REST and not inside a Mashup. 

A second call to read the Thing's property always had worked, but that was not a good way of implementation (because you are hitting the server two times). I suppose there is no other way other than 2 REST calls.

[Constantine]

Well, like I said, I know only one alternative way, which is using Async services. They run in separate threads and in separate DB transactions, so it should work just as well as two REST calls.

The tricky part is to return the result, which won't be possible in the context of the original REST call (async services return immediately, so you won't be able to get your property value in the same call). I don't know enough about design of your application to suggest anything specific, so I guess you'll need to figure it out yourself. Some questions to ask would be "Why do you need that value on the calling side?", "Can you get it later?", "Can you assign your user to the group earlier?" etc.

Also, since the user has the right to add to the group, you may consider adding visibility to that group to all things like "Thing" since the beginning. Since he has the right to modify groups, then using those groups doesn't improve safety in the first place, does it?

Finally, just a word of caution... you may get tempted into implementing something strange like:

1. Some waiting logic in the first service, that will wait for the 2nd one (async) to return;
2. Execute the 2nd REST call from the server side via ContentLoaderFunctions.PostJSON;

The advice for those is simple -- just DON'T. It's too easy to get it wrong (e.g. overlook Tomcat's limit on the number of concurrent threads), and it may break in the moment when you least expect.

/ Constantine