Impersonation of users

Feature Requests
1

A useful feature would be to impersonate a view of a user or their permission set. Whether that would be done by changing current_user via editor or through a feature would be a super useful way of testing/QA-ing apps.

9 Likes
2

Hey @stefancvrkotic!

This sounds like an interesting idea, would you mind sharing a bit more about your particular use case? It would be awesome if you could share what functionalities you have tied to user permissions that you would be looking to test, and also how you currently have them implemented.

3

Different teams of users use the same application, and certain features are hidden or limited based on their role (some views may be hidden or read-only based on it). The only problem here is visibility into how the dashboard looks on their end as many of those functionalities are tied to current_user and there is no way of previewing the UI besides going on a call with one of the set users. This could be circumvented by having a logon (replacing current_user functionality) but so far we've preferred the app load based on their email.

4

Got it, thank you for that additional context! Testing is something that our developer team is continuously looking at and the idea of mocking users and permissions is something on their radar. We'll let you know here if there are any updates on adding that capability :slightly_smiling_face:

5

Would love this too!

6

I'm surprised there hasn't been more interest shown in this. Count me as an upvote for this as well!

7

+1

8

+1

9

+1

10

I am running into this current issue as well. I would like a way to be able to specify a JSON object or pick another user to "become" and override the {{ current_user }} context.

11

I think just adding a test_user that we can set default values for and overwrites current_user would work. Add a project setting to enable/disable and good to go. extra credit for making test_user a project setting that's assigned at the Org level (so the org can define test data and restrict use by role per project) and for making test_user an array w a dropdown box and toggle switch next to 'Toggle Preview Mode' or something for lazy switching :sunglasses:

1 Like
12

I like this idea! Maybe in the App's setting's pick a test user and have {{ test_user }} available in the app.

I had the thought to make a transformer / query that reacted to a hash param to do something like:

return urlparams.hash.test_mode ? fetched_test_user : current_user

I don't really want to remove the references to current_user around the app though, and I don't want a user to "discover" my URL param

13

I don't really want to remove the references to current_user around the app though, and I don't want a user to "discover" my URL param

there's a setting to prevent query variable spoofing you might want to ensure is enabled:

image
image1075×798 87 KB

  • you could do something like
    return urlparams.hash.text_mode && curent_user.id === 'myId' ? fetched_test_user : current_user. you could use .id, .sid, .role, that way even if the param was discovered, unless they find a way to change their permissions it won't matter.

  • you could go try the new RPC stuff, to securely get ur test_user from the server.

  • you can also make a JS Query with something like:

Query Name:  testUser

if(current_user.id === 'myidnum' && debug.var === 'true'){
  let test_user = current_user;
  test_user.email = "new email";
  test_user.id = "test id";
  //.... and so on
  return test_user;
}
return current_user;
1 Like