"View comments" button under the community is not visible on other record versions (landing page)

[sakshamarora1]

Is your feature request related to a problem? Please describe.

Currently, if a request is accepted for a record version, the "View Comments" button under the accepted community only shows up for that specific version. It is stored in the "topic" sub-field of the request's payload.

Describe the solution you'd like

There should be a way to view the request comments from the landing page of all versions.

This will require to have the parent_id on the requests index, to be able to show the button on all other versions.

Solution proposal (to be discussed and finalized)

The link can redirect to the dashboard with the results containing all the related requests on the parent id.
This way if there is scenario where a community inclusion request of version was not accepted but the version 2 was accepted, the link will redirect to the requests dashboard containing all requests for those records in that community to be able to refer to the older request for reference.

Steps

1. Add parent id to the request index and update index (all new requests will contain parent_id)
2. Re-index the requests (where parent_id doesn't exist, all requests before we updated the index)
3. Update the link in the UI at the end (this way we avoid any searches on the parent till we have it indexed on all)

Additional context

Another thing to consider is that on the request dashboard currently there is no way to view all open/closed/owned/shared request in a single list view. We can have a way to be able to view.

[slint]

Not sure if discussed, but some alternatives I had in mind in the past:

Make use of the rdm_parents_community table (my preferred solution)

We have a table (based on this mixin) that actually has the following schema (note that record_id is the parent record PK):

invenio> \d+ rdm_parents_community;
+--------------+------+-----------+---------+--------------+-------------+
| Column       | Type | Modifiers | Storage | Stats target | Description |
|--------------+------+-----------+---------+--------------+-------------|
| community_id | uuid |  not null | plain   | <null>       | <null>      |
| record_id    | uuid |  not null | plain   | <null>       | <null>      |
| request_id   | uuid |           | plain   | <null>       | <null>      |
+--------------+------+-----------+---------+--------------+-------------+
Indexes:
    "pk_rdm_parents_community" PRIMARY KEY, btree (community_id, record_id)
    "idx_rdm_parents_community_request_id" btree (request_id)
Foreign-key constraints:
    "fk_rdm_parents_community_community_id_communities_metadata" FOREIGN KEY (community_id) REFERENCES communities_metadata(id) ON DELETE CASCADE
    "fk_rdm_parents_community_record_id_rdm_parents_metadata" FOREIGN KEY (record_id) REFERENCES rdm_parents_metadata(id) ON DELETE CASCADE
    "fk_rdm_parents_community_request_id_request_metadata" FOREIGN KEY (request_id) REFERENCES request_metadata(id) ON DELETE SET NULL

Which would allow to easily resolve via a record's parent what the request is for each community it's part of. I believe we're not using this in InvenioRDM, which is a shame since it's just a cheap PK query (compared to a search query).

This table also covers records that were added to a community without going through a request (in which case request_id = NULL).

---

Rejected ideas, but worth being aware of

Use the record parent_id as request topic (instead of the individual record version)

• This implies that there can only be one inclusion/review request ever associated with how a record (and all its versions) got added to a community.
• I recall discussions about being able to trigger the review request process for individual record versions (even after they've been added to the community), just for community curators to be able to comment and have conversations on each record version.
  • This might actually be an enitrely different feature though... Still, I would imagine in the UI we would call any links to such a request also something like "View comments" (for consistency).

Have a "smart" URL that redirects to the correct request

I.e. having an endpoint like [/api]/records/{recid}/communities/{comm_id}/request or similar, that redirects to whatever request was used to

• This assumes there is a request associated with the fact that the record is part of the community. Which is not the case always, e.g. for records that were added as part of migration or just programmatically to a community.

[zzacharo]

Not sure if discussed, but some alternatives I had in mind in the past:

Make use of the rdm_parents_community table (my preferred solution)

We have a table (based on this mixin) that actually has the following schema (not that record_id is the parent record PK):

invenio> \d+ rdm_parents_community;
+--------------+------+-----------+---------+--------------+-------------+
| Column | Type | Modifiers | Storage | Stats target | Description |
|--------------+------+-----------+---------+--------------+-------------|
| community_id | uuid | not null | plain | | |
| record_id | uuid | not null | plain | | |
| request_id | uuid | | plain | | |
+--------------+------+-----------+---------+--------------+-------------+
Indexes:
"pk_rdm_parents_community" PRIMARY KEY, btree (community_id, record_id)
"idx_rdm_parents_community_request_id" btree (request_id)
Foreign-key constraints:
"fk_rdm_parents_community_community_id_communities_metadata" FOREIGN KEY (community_id) REFERENCES communities_metadata(id) ON DELETE CASCADE
"fk_rdm_parents_community_record_id_rdm_parents_metadata" FOREIGN KEY (record_id) REFERENCES rdm_parents_metadata(id) ON DELETE CASCADE
"fk_rdm_parents_community_request_id_request_metadata" FOREIGN KEY (request_id) REFERENCES request_metadata(id) ON DELETE SET NULL
Which would allow to easily resolve via a record's parent what the request is for each community it's part of. I believe we're not using this in InvenioRDM, which is a shame since it's just a cheap PK query (compared to a search query).

This table also covers records that were added to a community without going through a request (in which case request_id = NULL).

Rejected ideas, but worth being aware of

Use the record parent_id as request topic (instead of the individual record version)

• This implies that there can only be one inclusion/review request ever associated with how a record (and all its versions) got added to a community.

• I recall discussions about being able to trigger the review request process for individual record versions (even after they've been added to the community), just for community curators to be able to comment and have conversations on each record version.

  • This might actually be an enitrely different feature though... Still, I would imagine in the UI we would call any links to such a request also something like "View comments" (for consistency).

Have a "smart" URL that redirects to the correct request

I.e. having an endpoint like [/api]/records/{recid}/communities/{comm_id}/request or similar, that redirects to whatever request was used to

• This assumes there is a request associated with the fact that the record is part of the community. Which is not the case always, e.g. for records that were added as part of migration or just programmatically to a community.

Hey @slint , I think we might need in the upcoming future the possibility to submit review per version and exactly as you said, I would envision that the button would be called "View comments" for consistency.

[sakshamarora1]

Thanks a lot @slint !
It looks like we are in fact using the rdm_parents_community table. See here
I found this way to find all related requests:

Current code

Updated working alternate:

-    record_requests = current_requests_service.search(
-        identity,
-        extra_filter=dsl.Q(
-            "bool",
-            must=[
-                dsl.Q("term", **{"topic.record": record["id"]}),
-                dsl.Q(
-                    "terms",
-                    **{
-                        "type": [
-                            CommunityInclusion.type_id,
-                            CommunitySubmission.type_id,
-                        ]
-                    },
-                ),
-            ],
-        ),
-        params={"sort": "oldest"},
-    )
-
-    return {r["receiver"]["community"]: r["id"] for r in record_requests}
+    parent = record._record.parent
+    community_requests = parent.communities._m2m_model_cls.query.filter_by(record_id=parent.id).all()
+    community_requests_found = {str(r.community_id): str(r.request_id) for r in community_requests}
+    # TODO: Currently no way to filter only community submission or inclusion requests
+    return community_requests_found

With this, the requests get displayed on each version of the record and it solves our issue. We should discuss about the per version review as this table will get affected from it and will result in a <parent_id,community_id> pair having multiple rows (for each request_id).

Important:

1. We should move the m2m query to the API as we currently don't have any method to retrieve the row from the DB
2. We lose the ability to filter requests based on the type, but then do we really require it?

CC @ntarocco @kpsherva @zzacharo