Private variable when working with Team Collections?

šŸŒ± Just Getting Started
1

Trying to use Postman Team so we can easily collaborate and share the API collections.

So far, weā€™ve used it individually and I have environment variables set up that define the url host, etc for the different environments.

I also set up variables for my username / password.

The request looks like this:

{  
  "username":"{{username}}",
  "password":"{{password}}"
}

Now problem is, with Postman Team, it shares all the variables, meaning I am forced to share my username/password as well. If I donā€™t use variables and hardcode the values, then everybody in the team will inadvertently share the same hardcoded value and/or they will end up keep having to overwrite each other values as they do their own testing.

Is there a ā€œprivate variableā€ feature where it stays in userā€™s local machine for such cases, so itā€™s not shared?

2

@tsurjo This has now been streamlined with our latest release of Postman workspaces, which will allow all recipients of your shared collection to use environments in their respective personal workspaces. You can share the intended collection within a staging workspace, from where the intended recipients can share it back to their respective personal workspaces, which will allow them to use this collection with their personal environments.

3

hI @kunagpal, thanks.

If I am doing it that way:

  1. When people make changes to the Collection in their personal workspace - would it be reflected back to the team workspace or do they have to manually ā€œcopyā€ it over everytime?

  2. When thereā€™s an update from other people in the team, do they have to reshare it to their personal workspace everytime?

  3. With personal workspace, it doesnā€™t share the team environment setting, that means everybody will need to set up a personal copy of the environment variable (eg. host url, etc)?

1 Like
4

Absolutely agree with the points made by tsurjo when using the team Workspace. For the purpose my team has eg, secrets held in environments, we can only use the team Workspace if we manually share to my Workspace each time we want to run a new version.

Of course if I then want to update that collection I need to go back to the team workspace and then make changes, and share again back to my workspace. This seems like a very manual and slow process.

In my mind the Team Workspace would then allow you to drop any of your personal environments from my personal Workspace.

5

Has this feature been released? If not is there a time frame for when it will be available?

6

Private variables are almost a necessity for a development project like this with security.

Yes we copy to our private workspace but them any changes have to be carefully merged back because more than one person can be making changes that need to be merged in.

7

I wish we had this too, we have our workspace set up great, except sometimes we stomp on eachotherā€™s environment variables. I wish there was just a per-user environment, just like the globals and regular environment.

8

@rlabrecque
I can think of a few things to help you out (these arenā€™t alternatives to the idea of private environments, Iā€™ll call them workarounds):

  1. You can maintain your own environments in your personal workspaces, and share (I donā€™t mean export and import here) the collections from a team workspace into your personal workspaces, and use your personal environments.
    Even when the collection gets updated by some other team member, youā€™ll always have the access to the latest collection since the source of truth is the same.

  2. In case you modify the collection, then you can fork it to your personal workspace, and use it with your personal environments, once all looks good you can merge your changes to the original collection and update the environment in the team-workspace accordingly.

  3. Make use of session variables

  4. If session variables donā€™t help you out,
    then thereā€™s something similar which is part of the Postmanā€™s roadmap which is ā€˜Role-based access control over the environmentsā€™, using this youā€™ll be able to control who can change what environment in a team workspace.

9

Just started using a team workspace today and was surprised (and disappointed) to see this is an issue.

I didnā€™t see this specifically mentioned above. But, has the postman team considered having another scope for environments. What Iā€™m looking for (and I think what people above were expressing) is a way to override certain environment variables with a ā€œlocal scopeā€. I.e., an environment variable thatā€™s only local and not shared in the workspace which would override the variables in the environment defined in the workspace.

This would, e.g., let you override email and password variables with your own email and password without requiring you to put that in a shared environment (which wouldnā€™t work well anyway since different people very likely need to use different emails / passwords :stuck_out_tongue: ).

Does that make sense?

10

Looks like you can do a workaround for my use case above by setting the ā€œcurrent valueā€ for the global (which isnā€™t synched with the team). It will just get blown away if the variables are updated. Works ok, but still not ideal. /shrug

2 Likes