Links in Related Documents show up inconsistently

[ibressler]

With default functional accounts, when logged with role archivemanager, there are links to the related documents in the respective section as shown here:

With role ingestor those links do not show up:

Regarding ACLs for datasets of authenticated users the difference between archivemanager and ingestor is only that the former can "reset", "destroyById", "deleteById" -> does the lack of these permissions prevent the links from showing up for the ingestor role or do we miss something here?

Thanks for any hints!

[stephan271]

Hmm, that is strange. But I dont think, that this is catamel/ACL related. I assume there is some catanie/GUI side logic which leads to this effect. @henrikjohansson712 any suggestions what might cause this effect ?

[henrikjohansson712]

Looks like it's because of this selector, that only returns true for admin and archiveManager: https://github.com/SciCatProject/catanie/blob/3911164a2b41c862843e1854a18ac14b81954a84/src/app/state-management/selectors/user.selectors.ts#L34

This is then used to set the editingAllowed variable here: https://github.com/SciCatProject/catanie/blob/3911164a2b41c862843e1854a18ac14b81954a84/src/app/datasets/dataset-details-dashboard/dataset-details-dashboard.component.ts#L293 which is used to decide whether the user should see the "full" version or the read-only version of the dataset details view.

My suggestion would be to simply add ingestor to the list of functional accounts in the selector mentioned above.

[stephan271]

I think that would mix two topics: select if data is editable and select if the information is presented as text or as URL links. Cant we always display the data as URL links and let the backend decide about the access rights ?

[nitrosx]

@marcoleorato: would you mind checking if your pull request fixes this issue too? Thanks

[marcoleorato]

I looked into it a bit, my PR doesn't alter the way it works right now. But this feels related enough to the changes I was doing that it would make sense to have it in it. For the possible solution what @henrikjohansson712 said is probably the best one, showing it as link or not based on getIsAdmin function, and adding ingestor to it, feels better as non clickable links are confusing.

But, although it might be considered a different issue, I think this open up a another point of who should be able to see the proposal name?

Currently I can see around 4 possible user case: an anonymous user (anyone not logged in), logged in user (any user that is not owner/functional), logged in owner of the dataset/proposal, logged in functional account. And 3 actions that can be done: View the name of the proposal on the dataset details, Open the Proposal on the /proposals/:id page and Edit the proposal. Leaving with this table as of the current version:	User	View	Open Proposal	Edit
Anonymous	Yes	No	No
Logged User	No	No	No
Owner	Yes	Yes	?
Functional Acc.	Yes	Yes	?

This doesn't feel consistent, should I also hide the proposal name for anonymous users or show it for a logged in user? I hope @stephan271 can help with this choice. If the choice is to hide it also for anonymous user the show as link/normal text problem doesn't really exist as only people that can open it (and need the link) will see it. I'm not sure about the editing but that part is in the proposals that I've not touched.

[stephan271]

I agree to the first pint (add ingestor to getIsAdmin), its already a better solution than the current one.

Concerning the visibility of the proposal name: not sure if I understand this correctly: what do you mean by name of the proposal (the title ?). Do you want to have different access rights for different parts of the proposal information ? The latter would be quite difficult to implement, and needs a change in the backend. I would not want to go for this. But probably I misunderstood the point.

[nitrosx]

I would say that only authorized users and functional accounts can access and view proposals. So Anonymous user cannot view the proposal or the link to it.

[stephan271]

Unless they are published , I assume.