How much access do Team users require in order to have both read-only access to the “main” collection, but also enough permissions to create their own fork within the same workspace if they need to submit changes?
In a nutshell, I’m currently looking to get a Team workspace (Professional lic) setup as follows:
A “main” collection, which should be forked by team members (not be edited directly), instead, all contributions be Pull Requested into.
(ideally, with all but Admins being able to ever delete it, for fear of accidental deletion)
Team members to have only “Viewer” access to the “main” collection, who can either use the collection directly in read-only mode (if no changes required)
…OR…
Have the ability to fork the collection into their own copy (also stored within the same Workspace, presumably, so that Editors have secure visibility while doing approval), if they need to make any changes to the “main” collection.
Two “Editor”(?) users that will review and approve any Pull Requests from forked collections. They should also follow the same process (though I believe Postman currently doesn’t have a way to enforce this, as Editors need ability to make changes as part of reviewing PR’s)
One to two admins to manage the Team, where necessary, but more at an account level.
…and I’m looking for guidance as to what Roles (Workspace, Collection, etc.) we should use in order to achieve the above (particularly around the standard contributing users, per the opening question).
A response in this thread suggests that People with “Viewer” workspace role
should be able to Fork a collection into the same Team workspace. However, I thought “Viewers” didn’t have the ability to create a collection (unless “forking” is treated differently to creating)
Rightly or wrongly - I’m assuming this should be a standard flow
(e.g. like in source code - you don’t allow direct push to branch, have managed by peer-reviewed Pull Requests).
But I don’t seem to see any official Postman docs on how a Team should be setup for this.
…and the lack of any response here (at least so far) makes me wonder, am I under the wrong impression?
So, if the user is View Only in the Master workspace, they would need to fork into another workspace in order to work on the Fork.
There is one caveat.
If they want to then submit a PR, they the collection would need to be accessible by the Master workspace (IE. the collection would need to be in a Team workspace - not personal, public, partner or private)
Thanks @ms-cs-postman for confirming my suspicions that “Viewer” permissions are going to be a problem for users. However, this makes me even more curious to know how Postman suggest we should setup such workspace/permissions (as I feel this could be quite a common scenario).
Coz otherwise, (to me) it almost seems like the “Fork” functionality is semi-redundant, if there’s no way to make normal (non-Editor) users to NOT have the ability to edit the “master” collection directly (thus forcing all edits from normal users to be via forks). I’d suggest relying on users always remember to do would be …unreliable.
Are we saying, for example (and for the record, I already don’t like this suggestion) - that there needs to be a separate Team workspace, that standard users have edit writes to, just to store users’ forked collections? (e.g. the “master” collection is in Workspace A which they have “Viewer” access to, and Workspace B they are normal/“Editor” users), then they raise PR’s across Workspaces?
(Would this even work? and is there a better/cleaner option, without also giving users the ability to edit the “master” collection directly?)
The suggestion I made with multiple workspaces was an attempt to also keep the master workspace clean without hundreds of collections.
You can also set permissions at the collection level, making users view only.
I would suggest using User Groups to potentially make this easier vs. having to set this by user.
Then users can fork the collection in the same workspace (if they have Edit rights at the workspace level)
If you want something more advanced or simplified - I would suggest using our Native Git workflows which uses branching in your Git repo for version control