Configuration user vs. Admin user workflows

Hi Team

I have noted that Configuration Users cannot publish configured environments. I have gotten around this by making Configuration Users into Admin users. But this seems like giving a lot of permissions to gain just this one functionality.

How have you managed this difference in your workflows?


Deployment: Are you using the hosted EaaSI service, or a local node? EaaSI Oz / aarnet hosted node.
EaaSI Version: This corresponds to the release branch/installer version used to deploy your instance. This information should be available in the Manage Node menu, if accessible
Browser: The name and version of the browser you are using to access the EaaSI UI, if applicable

Description: Please describe your issue in as much detail as possible, including name + ID of any relevant environments, software or content. You can also attach screenshots or relevant error report files.

Are you able to reproduce the issue or did it happen once? What steps can you take to repeat the issue? What did you expect to occur and what was the actual outcome?

Urgency: If possible, please give an indication of how urgently the issue needs to be addressed - is there a timeline or deadline (e.g. upcoming demo, researcher request, etc.) that EaaSI support staff should be aware of?

Hi Cynde, this is indeed not really the ultimate goal with the different permission levels, but for the moment, outside of creating a user account with shared credentials (multiple people logging in with the same user account) you’re right that this is basically how I would address sharing Environments between accounts.

We will have a new dev update out soon, but with the more stable 2021.10 release out, one of the focuses is to work more on access control and introduce environment link sharing, along with a new “guest” user permission level (who would e.g. only be able to view environments shared to them explicitly). Taken together, the goal with these improvements would be:

  • allow Configuration Users to “share” (a new function, not 100% this will be the word for it yet) their private environments with other users in their organization/node (without “Publishing”)
  • allow Admins to have some kind of oversight/way to view Configuration User’s private environments even if those are not “shared” to the organization

The idea here mainly being to decrease reliance on the “Publish” function as a way of just showing and using Environments between individual users and limit it to its original design of exchanging Environments between nodes/organizations, where we assume the Admin-level oversight is desirable and the restriction for Configuration Users would make more sense.

I’m curious if that would address how you’re currently thinking with your workflows? Or even if Configuration Users could share more widely within their node, would you still see a need for them to be able to Publish, but not have access to the other Admin-level controls? (user management, setting up OAI-PMH sync, etc?)

Hi Ethan

This is interesting to hear the different ways of sharing.

I have been making accounts in other people’s names, creating environnments that I want to share with them only, then giving them logins to these accounts. Instead of making the environments public, because the content is sensitive and not to be shared with everyone on the node.

In other situations, I have had configuration users configuring environments that I want to be public. But in order for them to do that, I have to change their permission level to Admin. Giving them more privileges than I am totally comfortable with.

It would be nice to, as you suggest, as an Admin, be able to look at the configuration user’s accounts and see what they are up to.

“Guest” user sounds like a useful way to share environments with a non-configuring user.

Thanks for the detailed answer. Looking forward to more fun in the new year!