Kickoff Project Manager Docs #1197
Conversation
| Collaboration | ||
| ------------- | ||
| Collaborative projects need properly configured directories to exist in, which may | ||
| vary on the types of collaboration you would like to enable. Like other actions in |
There was a problem hiding this comment.
I realize that the 'types of collaboration' referenced here is a little nebulous, but here is what I had in mind.
Basically, we should support both 'read-only collaboration' (collaborators can view, copy, and execute files, allowing them to run any launchers and workflows) and 'full collaboration' (collaborators have identical permissions to project owner).
I envision certain centers being uncomfortable with 'full collaboration', and so they could configure their directories to never allow non-owning collaborators to edit files. I also envision some project owners wanting to restrict their collaborators from editing specific projects (or limit 'full collaboration' to individuals within their group), so this would be an option in the project settings.
For these reasons, I would say that we recommend centers create shared directories with full group permissions, giving individual project owners the ability to restrict projects to read-only if they wish. These permission restrictions would only affect the project root (not shared root or group folders), and so would not need additional involvement from an admin.
| vary on the types of collaboration you would like to enable. Like other actions in | ||
| Open OnDemand, it will operate as the logged in user and never exceed the UNIX | ||
| permissions of the directories and files it operates on. This means there are several | ||
| different approaches you may want to take depending on your file system's account and |
There was a problem hiding this comment.
We should also put some thought into other approaches to file permissions and how those will cooperate with the PM. (I know some places use our Allowlist functionality, but is this an alternative to group-level management?) Basically we should be minimal with our required permissions in order to remain compatible with whatever strategies people are using, but advocate and pull examples from an OSC inspired format. (Even OSC doesn't currently have these permissions yet, but we should make sure they are comfortable implementing our recommended approach).
| #. Any directory in ``OOD_SHARED_PROJECT_ROOT`` and above must have at minimum ``r-x`` permissions | ||
| for all potential collaborators. | ||
|
|
||
| #. Any group directory directly below ``OOD_SHARED_PROJECT_ROOT`` should have ``rws`` permissions |
There was a problem hiding this comment.
We can also definitely add a section below explaining what these permissions mean and how to enact them, like setgid to get the s permission. But this can wait until we nail down all the permissions we need.
This PR is mainly about nailing down the directory configuration we want for the project manager, specifically the numbered items at the bottom of the page, in addition to explaining the
OOD_SHARED_PROJECT_ROOTenvironment variable. The rest is the bare minimum to provide the structure leading up to these requirements, and I have absolutely skipped some key in-between content. I also placed a direct navbar item forProject Managementfor our convenience, mostly because I don't know exactly how we will end up fitting this section in to the documentation structure. While we can discuss the best approaches here, the main focus of this PR is to discuss the PM details so that we have a source of truth we can refer to as we continue development, even if we don't merge this until we document the rest of 4.1.View the new page at https://osc.github.io/ood-documentation-test/initialize-PM-docs/how-tos/project-management/project-manager.html