Deciding project access requests
A project’s contents are membership only. Someone who can see a project in the list but is not a member of it lands on a short screen explaining that, with a button to ask for access. Those requests arrive here.
- Open Organisations, click into the organisation, then click into the project.
- Open the Access Requests tab. Pending requests lists everyone waiting, with their Role, the date they asked, and the Note they wrote if they wrote one. A client account is marked, so it is clear when the person asking is external.
- Click Approve to add them to the project immediately, or Deny to decline. Denying opens a small box for a reason, which is optional and is passed on to the requester.
- Decided requests move to the Decided section below, which keeps who decided and when.
Approving does the same thing as adding the person by hand on the Project Overview tab: it creates the project membership and pulls them into the project’s support chat. Either way the person is notified, so nobody has to be told separately that they now have access.
The tab is only visible to roles that carry the accessRequests resource. Grant read to let a role watch the queue, and update to let it approve and deny. Set both in the role editor on the Dashboard under the Roles tab, the same way as any other resource. Requesting access needs nothing extra: anyone who can read projects can ask.
Approvers in the organisation are notified when a request is filed, so a queue nobody is watching is unlikely. Requests are capped per person per project, so a declined request cannot be re-sent on a loop.
See this on your own workflow
This is the product as it stands today. A call is where you find out which parts of it your team would turn on, and what a deployment looks like.
partnerships@dhcertainty.com