🐛Link role update

[AntoLC]

Purpose

When a child document is restricted, but have a different computation (authenticated), the link role could be updated from link-configuration and gives a 200 response, but the change did not have any effect on the computation because of the link_reach being still restricted.

Request URL https://docs.numerique.gouv.fr/api/v1.0/documents/[DOC_ID]/link-configuration/
Request Method PUT
Payload:{"link_role": "editor"}

See: #1283

Proposal

We added some validations steps to be sure the link-configuration can be updated correctly.
We adapted the front to follow the new types requirement on link-configuration (link reach mandatory).

🥅(backend) link role could be updated when restricted document
🩹(frontend) add computed_link_reach on PUT link-configuration

[AntoLC]

I find a bit strange to have link_role by default in "Reader" when the reach is by default "Restricted", should not be "None" ?

docs/src/backend/core/models.py

Lines 370 to 377 in 95c4e06

	link_reach = models.CharField(
	max_length=20,
	choices=LinkReachChoices.choices,
	default=LinkReachChoices.RESTRICTED,
	)
	link_role = models.CharField(
	max_length=20, choices=LinkRoleChoices.choices, default=LinkRoleChoices.READER
	)

[sampaccoud]

I think you should use the existing get_select_options method to ensure unicity of the logic. Also, should we add something to abilities for the frontend to know? This makes me wonder how did you bump into this and was it really a functional issue because actually, link_role is ignored and irrelevant when link_reach is restricted.

[AntoLC]

Ok, actually I was misleaded, the root problem is how max_role is computed when a child is still in a restricted type (after being created).

docs/src/backend/core/choices.py

Lines 106 to 113 in 0775752

	max_role = max(
	(
	link["link_role"]
	for link in ancestors_links
	if link["link_reach"] == max_reach
	),
	key=LinkRoleChoices.get_priority,
	)

[sampaccoud]

If I understand the problem correctly from the issue, the backend is correct but the frontend should set link_role to authenticated AND link_role to edit for it to be overriden.... doing what tou propose would lead to side effects and the problem would still be the same downstream or for authenticated vs public...

[sampaccoud]

Said differently: you can't expect to override an authenticated computed role by setting a different role for another level of reach!!

Technically in the frontend, you should use the computed link_reach to set your override and not the current document link reach

[sampaccoud]

And I agree that there should be a validation to make sure that only allowed combinations are passed as per get_select_options

[AntoLC]

Technically in the frontend, you should use the computed link_reach to set your override and not the current document link reach

The front does not set the current document link reach.

Request URL https://docs.numerique.gouv.fr/api/v1.0/documents/[DOC_ID]/link-configuration/
Request Method PUT
Payload:{"link_role": "editor"}

But yes, if we force the link_reach in the payload with the computed one, the problem does not occur anymore.
I suppose link_reach should be mandatory so to avoid mismatch, plus yes a validation to not be able to have these kind of payload: {"link_reach": "restricted", "link_role": "editor"}

[AntoLC]

I adapted the serializer validation with what was made initially, I think it covers all the cases.
Feel free to take over.

[sampaccoud]

I don't get it. The link rôle of a restricted document is irrelevant so why take it into account? Can you try explaining in PR description what is the functional problem you face?

[AntoLC]

I tried to be more descriptive.
By following the issue #1283, you can reproduce the problem in production.