Add attribute with additional information for the user service to the datapackage

[AndyDaniel1]

We have a growing number of datapackages with specific requirements for the data dissemination (e.g. specific contracts). To give the user service a quick overview of what the requirements are, we should add an attribute "Bemerkungen für den User Service" "Remarks for the User Service" to the data package. This field should only be displayed in the interface and remain hidden on the detail page. In the course of an order process, the attribute should be transferred to the DLP. We need to decide where in the DLP the information should be displayed. @UteH does it make sense to open a corresponding issue in the DLP repo?

If possible: The information could be displayed on the data package detail page for the role "publisher".

[tilovillwock]

I had some misconceptions about the inner workings of the order process between DLP and MDM and as such my remarks regarding the query parameter issues and encoding are kind of moot now. I did some research and discovered that the following things are in fact already implemented:

• both order product types (analysis package and data package) already have an annotation attribute that is being stripped of markdown tags and persisted that way in the database on the MDM side
• opening the Shopping Cart URL in DLP triggers a request to fetch the entire order object (including the products) from the MDM Order API and persists it into the DLP database before the application form is even rendered (so no transfer of data attributes via URL beyond the order ID)
• order data attributes are only visible in the DLP application form if they're added to the wizard template (so sensitive attributes would remain hidden)

As a consequence we need to discuss two things:

1. Where should the remarks for the user service be placed? Right alongside the other attributes like Version, Software, Annotations, etc?

2. How do we handle access to the Order API It's my understanding that the remarks are supposed to be privileged information. Right now the Order API has no access restrictions which would expose any sensitive information. We could establish a limited MDM API access role that can only be used by the DLP backend and make the Order API non-public (as in you need to be authenticated to access any order).

@AndyDaniel1 @UteH

[AndyDaniel1]

1. yes, below software, above annotations

2. The "remarks for the user service" should only be accessible for publisher (MDM) and Antragsbearbeitung (DLP) and this should also be true for the access via API. The best solution for us would be to keep all information of the order API publicly available, except the "remarks for the user service", would that be possible?

[tilovillwock]

• on the DLP side we need to filter out the rendering of sensible attributes depending on the role (TWIG template)
• Order API needs to filter out sensible attributes if the request is performed without authentication

[AndyDaniel1]

@tilovillwock The publisher should be able to filter data packages according to this attribute.

[tilovillwock]

@AndyDaniel1 a few questions regarding the search for and visibility of the attribute:

1. You mentioned that if possible we only show this attribute to users with the role Publisher on the detail page. Should the search for this attribute also be limited to the "simple" search for the publisher?

2. We expect this attribute to be rather heterogeneous with possibly multiple sentences. Are we sure this won't confuse the user in terms of what can be expected as a result? Especially since this is not rendered as part of the the result card?

[AndyDaniel1]

@tilovillwock I have thought about it and I think that it should not be necessary to have a full text search, but to have a filter that separates the data packages with additional information for the user service from those without (simple boolean: additional information true/false). I think the filter should be placed in the project overview (not in the general search) in the cockpit as an addition to #3224.

[AndyDaniel1]

todo @AndyDaniel1 : Update process documentation & user service documentation when issue is implemented and tested

[AndyDaniel1]

The filter does not work:

[AndyDaniel1]

Now it works. Does the index take some time to update?

[AndyDaniel1]

@UteH please test if the transfer to the DLP works.

Nutzungszwecke und Zusatzinformationen Userservice

• Datenpaket, Analysepaket
• unangemeldeter User sollte es nicht sehen
• Antragsbearbeitung sollte es sehen
• DZHW Admin?

[UteH]

Review remarks (still in progress!)

1. substantially

MDM:

• signed in as publisher I can see both - ok 🟢
• signed in as data provider, I can see the information for the user service (for projects I am assigned to) for unreleased projects -> is that ok? Seems ok for me ❓
  • after release not anymore

DLP:

• as data user who should only see regular annotations, I can see the annotations for user service but not the regular annotations: 🔴
• same as application manager (Antragsbearbeitung) (DLP role) who should be able to see both 🔴
• same as DZHW administrator (DLP role) who should be able to see both 🔴
• same as administrator (DLP role) who should be able to see both 🔴

other

1. Display of information

for analysis packages, the annotations are already displayed in the first step in the DLP. For data packages, the (userservice) annotations are only visible in the final summary and after submitting the application - harmonize?

2. DOI link is broken

• the DOI link is broken, it only leads to https://doi.org

3. MDM link

• (new Issue, talk to @AndyDaniel1): I think we don't need the MDM link anymore as we have German landing pages now; I think that's why we had both initially

[UteH]

@AndyDaniel1 sorry, I had overlooked the testing assignment earlier.

I tested (see above), I can test again after rework

[tilovillwock]

the DOI link is broken, it only leads to https://doi.org/

@UteH We are going to investigate this as a separate Issue (#3313).

I think we don't need the MDM link anymore

@AndyDaniel1 if you agree we would fix this as part of #431.

[AndyDaniel1]

@tilovillwock agreed 👍 .

[AndyDaniel1]

The filter seems not to be working. Will have another look at it next week.

[AndyDaniel1]

[tilovillwock]

The filters should start working again, once we deploy the bugfixes for #3216 to the testing stage. After the last JDK some GSON calls (Google JSON Library) were replaced with Jackson calls (Spring bundled JSON library) resulting in different field names in Elasticsearch. Hence some of the filters stopped working.