If a record is included in Community A and Community B, then:
- Members of Community A should only be able to view the inclusion request for Community A and not Community B (unless they are also members of Community B)
- The owner of the record should be able to view all requests
- Manually added reviewers of any request should be able to view it regardless of community membership
By "members", we are referring to curators and above. "Reader"s cannot access requests. See the list of permissions here.
Right now, members of Community A can view the inclusion request for Community B and vice-versa, which is bad.
See here for a potentially useful Claude plan on how to implement this
Subcommunity handling
This is relevant if we want to move this to RDM
We need to ensure that parent communities can see the request of children ones.
Let's say we have two communities, Parent and Child
When a record is submitted to Child, the request is created with Child as the receiver. While it's a draft, the parent record does not have any communities in its list. Therefore, based on the current permissions, only the curators of Child can view or approve the request in any way.
Once the request is accepted however, both the Parent and Child communities are added as communities on the record's parent. Which means that on the basis of the RecordCommunitiesAction grant, curators of either Parent or Child can now access the accepted request. This gives this very weird-looking list where both of the "View comments" buttons actually point to the same request. See here for an example
Additionally, curators of Parent cannot see the "requests" tab on Child even if they have access to several (but not all) requests to Child. The submission request for a record to Child also doesn't show up in the requests tab of Parent. So the only way to access it is via the record page itself.
So we need to do the following things:
-
Since we are removing RecordCommunitiesAction("curate") from can_manage, I would probably go towards an approach of giving parent community members fully identical access to the child communities, by modifying the CommunityRoles generator. This should be relatively uncomplicated, we will just have to make sure we don't introduce an extra OS query since that would slow things down
-
we need to change the behaviour of the requests tab so that it shows up on the subcommunity if you're a curator of the parent. This might automatically happen if we change the generator.
-
We need to change the behaviour of this list somehow so it doesn't show the request and the parent community in two places
If a record is included in Community A and Community B, then:
By "members", we are referring to curators and above. "Reader"s cannot access requests. See the list of permissions here.
Right now, members of Community A can view the inclusion request for Community B and vice-versa, which is bad.
See here for a potentially useful Claude plan on how to implement this
Subcommunity handling
This is relevant if we want to move this to RDM
We need to ensure that parent communities can see the request of children ones.
Let's say we have two communities, Parent and Child
When a record is submitted to Child, the request is created with Child as the receiver. While it's a draft, the parent record does not have any communities in its list. Therefore, based on the current permissions, only the curators of Child can view or approve the request in any way.
Once the request is accepted however, both the Parent and Child communities are added as communities on the record's parent. Which means that on the basis of the RecordCommunitiesAction grant, curators of either Parent or Child can now access the accepted request. This gives this very weird-looking list where both of the "View comments" buttons actually point to the same request. See here for an example
Additionally, curators of Parent cannot see the "requests" tab on Child even if they have access to several (but not all) requests to Child. The submission request for a record to Child also doesn't show up in the requests tab of Parent. So the only way to access it is via the record page itself.
So we need to do the following things:
Since we are removing RecordCommunitiesAction("curate") from can_manage, I would probably go towards an approach of giving parent community members fully identical access to the child communities, by modifying the CommunityRoles generator. This should be relatively uncomplicated, we will just have to make sure we don't introduce an extra OS query since that would slow things down
we need to change the behaviour of the requests tab so that it shows up on the subcommunity if you're a curator of the parent. This might automatically happen if we change the generator.
We need to change the behaviour of this list somehow so it doesn't show the request and the parent community in two places