Widget runtime permissions

[jensc]

Hello Community,

As I have started working more with permissions in Thingworx recently.

I was wondering how other people in the community use permissions when setting visibility or disabling widgets in mashups.

My current thought is to set some different session parameters when the master mashup loads like;

Master loads -> SetGlobalSessionPermissions

The service SetGlobalSessionPermissions could look something like this:

const userGroups = Resources["CurrentSessionInfo"].GetCurrentUserGroups();
  
  const isAdmin = userGroups.rows.toArray().find(e => e.name === 'Admin');
  if(isAdmin) {
    Resources["CurrentSessionInfo"].SetGlobalSessionBooleanValue({
      name: "IsAdmin",
      value: true,
    });
  }

  const isViewer = userGroups.rows.toArray().find((e => e.name === "Viewer"));
  if (isViewer) {
    Resources["CurrentSessionInfo"].SetGlobalSessionBooleanValue({
      name: "IsViewer",
      value: true,
    });
  }

Then in any mashup we could use these session parameters to set visibility or enable/disable widgets.

This approach minimize the need for creating services in each mashup to check what permissions a user has.

However, there seems to be one drawback with it. The mashup that is loaded in the masters ("Page Mashup") widget gets loaded at the same time(?) as the master. So if you have anything that uses this session parameter there it wont work correctly.

I was wondering if perhaps there was any way to make sure that the master loads before anything else starts loading?

My current thought for a workaround would be to use the "Refresh" event on the "Page Mashup" widget in the master after the service to set the session parameters has run.

This does increase the load some and for my first (and only test so far) it didn't really work as I thought.

I think it would be great if we could get some inspiration or lessons learned from the community.

Thanks,

Jens

[iguerra]

I also get problems by using SetGlobalSessionBooleanValue ... trying to drive some widget behaviour on an "already opened" mashup.

Changes on session values are not pushed to the mashup.

I don't know how web browser will open master and contained mashup ... probably at the same time as you have seen.

Fortunately I don't have many widget to hide based on groups, I work more with menu and native hiding with group membership (so I will hide menu entry and the relative mashup). 

For mashup I still use a service (launched at mashupload), only on mashups that requires hiding of some widget, and I pass a "group name" as parameter  .. so I can manage different levels based on group membership (e.g. ... a widget is disabled by default ... and become enabled is the user is part of group "x" (or "y"....)

[jensc]

Hello @iguerra,

Yeah, I knew that setting parameters inside of a service (so on the server) wouldn't affect runtime. But I had hoped that the master would be loaded before loading the contained mashup. That is why I decided on doing it in a little bit of a roundabout way as you can see on my follow-up post.

I have previously also done as you have, and still do try to keep it contained on a menu level (and not give visibility/design time permissions on mashups that users shouldn't get access to). However I felt like having mashups with shared permissions where some user should be able to click a button and other shouldn't, I wanted to limit the calls made do the server each time the user enters the mashup.

I think it is good to share how we use these things as I feel like PTC is somewhat lacking in giving best practices on things like this.

Regards,

Jens

[jensc · Accepted solution]

Hello,

I should probably say what my solution to my own problem was.

Instead of setting the session parameter inside of my service using the "SetGlobalSessionBooleanValue", I pass the boolean values back into the Master mashup and set the session parameters that way.

This is because setting session parameters in a service does not affect the runtime before a refresh has taken place.

This way, even if the service to get the permissions takes some time, eventually the session parameters will be set and anything that uses them will be "triggered", like visibility or disable events.

Regards,

Jens