Without the ability to save variables or create an environment, the guest access feature is completely handicapped and useless.
Our collections use variables to switch hostname between our development and production servers. So the syntax of a request is like this:
https://{{hostname}}/users/login
We cannot find a way to make this work because there is no environment or variable storage in the collection (or globally in the guest account). So we cannot just tell the guest to make a onetime change to define the hostname variable in their environment and have it apply to all requests in a collection.
Not only that, our requests use an inherited Bearer Token defined at the collection level during login. The initial login runs a post-response script to populate the token value in the environment, like this:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable(âtokenâ, jsonData.token);
So this also wonât work because thereâs no environment. This means the login credentials have to be applied to each and ever request. This is frustrating.
A Guest invited to any collection has view-only access to that collection, and collection artifacts like environments and variables are not shared with the guest. An environment in Postman is tied to a workspace and not to a specific collection; therefore, giving a guest access to that environment can give them access to variables used on other collections that are not very relevant to the users themselves.
I recommend that the guests fork this specific collection and set up their own environments. They only need to do this the first time.
Alternatively, if youâre comfortable with it, you can invite them to your workspace with viewer only access. This should give them access to environments in that Workspace. If you do this, remember to store variables you want to share across your team as âinitial valuesâ and not âcurrent valuesâ as current values are not synced with Postman Cloud and hence will not be shared with anyone with access to that Workspace.
You said: âI recommend that the guests fork this specific collection and set up their own environments.â Guests cannot edit or fork anything. Perhaps you are suggesting that I export JSON data and send it to my colleague, rather than making them a guest?
You also said: âinvite them to your workspace with viewer only accessâ. Isnât this what Guest access is - viewer only? And what are âinitial valuesâ and âcurrent valuesâ. I canât see any variables in the guest account. Initial values seems to be a feature of private workspaces only. Could you be more specific about how to create viewer only access with variables?
Another thing I would like to point out is that inviting my guests to become team members is also problematic because there is no privacy. That is, any team member can see and edit any collection in any team workspace. Even if I wanted to limit a team member to a specific workspace, there is no way to accomplish it in Postman.
A guest has access to variables in a collection that has been shared with them. If you click on the name of the collection and navigate to the âvariablesâ tab, you should see this screen.
I was hoping to use this feature to share collections for colleagues / partners who just need to run the collections occasionally and donât need to edit or contribute back.
Iâve hit a couple of issues. The environment is not shared as you have mentioned above.
But the bigger issue for us is we have started using the Package Library to reduce duplicated code and this is also not supported for guests.
I thought this was going to be a great feature until Iâve drilled into it. Hopefully it will become more usable over time.
Yes, the package library isnât shared with guests. Itâs a relatively new feature that we are constantly improving and making better and Iâll do well to relay this feedback to the relevant team. Theyâve been actively looking into sharing access for the package library and right now, you need to have write access to the collection(editor role upwards) to atleast see scripts in the package library.
I am not trying to be argumentative or annoying, but I have to respond to your assertions.
You said: âA guest can âforkâ a collectionâ. Indeed, the fork icon is visible to guests. However when selecting this icon, the following text is displayed: âYou need to request for a role change to perform more actions on this collection.â So clearly, guests cannot fork any shared collection.
Thank you for clarifying what is meant by âinitial valuesâ and âcurrent valuesâ of variables. I now understand what you mean when you say: âcurrent values are not synced with Postman Cloudâ.
You said âRoles can be managed at the⊠workspace levelâ. You need to qualify this as only available to those with Enterprise Plans. Otherwise the ability to âChange Accessâ is limited to âonly meâ, âteam membersâ and âpublicâ. Since the collection is already accessable to the team, the only real choice is to make it private, which voids the sharing. As I said previously, there is no collection or workspace privacy because any team member can see and edit any collection in any team workspace.
You said: âA guest has access to variables in a collection that has been shared with them.â To test this, I added a variable called âserverâ to a collection in a team workspace, set the initial value and then created a guest link (ie- a Shared URL with permission to request an upgrade to a team member). In another browser I opened the guest link. When I clicked on the name of the collection and navigated to the âvariables tabâ I saw the message âNo variables in this collection - Request additional access to this collection to add variablesâ which is clearly an upsell to become a team member. I stand by my assertion that there is no environment or variable storage in a collection when accessed using the guest feature.
So in my testing I find that most of your assertions are not valid, at least for those not having the luxury of an enterprise plan.
Yes. This is correct. Before a guest can fork the collection, the team admin first needs to approve the fork requests, and the guest needs to be converted to a developer on the team.
To give viewer-only access to a Workspace, you need at least a professional license.
I am not able to replicate this on my end. If you take a look at the screenshots I shared above, you will see that the variables are viewable, but only the current values are modifiable.
One thing you could do here that wonât require you to obtain a license is âshare your collection via the API.â This option provides the guest with the collection in JSON format, and they can import it into a separate Workspace using that same URL by clicking the import button to the right of the name of the Workspace.
For now we are working arround it for now by merging environment variables in to the collection variables and removing any references to the package library and adding those functions to the collection too.
I know itâs not ideal, as it more work maintaining two collections when sharing work, but at least we donât have to export the collection & environment data and pass it arround that way.
.
