Modify event short

[ila131]

Hey Christian, as requested from our communication, I added 'Document Name' to the Files Table in EventShort. Additionally, I updated the technologyFields tags as they requested, by deleting 'Alpine' and modifying 'Food' to 'Food & Health'.

Have a nice evening,

Ilaria

[gappc]

Hey @ila131, thank you for that change, but according to the OpenAPI spec of the Tourism Domain there is no DocumentName property for the EventDocument type (check here under Responses -> Schema: https://tourism.opendatahub.com/swagger/index.html#/EventShort/SingleEventShort).

Did you have something else in mind?

[sseppi]

Hey @ila131, thank you for that change, but according to the OpenAPI spec of the Tourism Domain there is no DocumentName property for the EventDocument type (check here under Responses -> Schema: https://tourism.opendatahub.com/swagger/index.html#/EventShort/SingleEventShort).

Did you have something else in mind?

Hi @gappc , the request of the client wasn't related to the EventDocument type but to the Documents (a new property implemented by Rudi) type that is an array of documents that the user can upload. As you can see in the screenshot attached, the single items of the Documents have also the DocumentName property.

The final goal is to provide the possibility to see and modify the Document Name in the following EventSort view of the Data Browser.

@ila131 do I'm right? Please correct me if I'm wrong.

[ila131]

Hey @ila131, thank you for that change, but according to the OpenAPI spec of the Tourism Domain there is no DocumentName property for the EventDocument type (check here under Responses -> Schema: https://tourism.opendatahub.com/swagger/index.html#/EventShort/SingleEventShort). Did you have something else in mind?

Hi @gappc , the request of the client wasn't related to the EventDocument type but to the Documents (a new property implemented by Rudi) type that is an array of documents that the user can upload. As you can see in the screenshot attached, the single items of the Documents have also the DocumentName property.

The final goal is to provide the possibility to see and modify the Document Name in the following EventSort view of the Data Browser.

@ila131 do I'm right? Please correct me if I'm wrong.

Yes, exactly.

[gappc]

@sseppi @ila131 if I get this right, there are now 2 properties in the EventShort dataset that take care of documents, EventDocument and Documents, is that correct? As an API consumer I find that design a bit confusing, what is the difference? Which one to chose? Would it be possible to have one of the two properties only?

@ila131 if you want to work with the Documents property, you need to adjust the value for pathToParent in event.ts. Then you'll have to check if anything works as expected (e.g. upload).

[sseppi]

@sseppi @ila131 if I get this right, there are now 2 properties in the EventShort dataset that take care of documents, EventDocument and Documents, is that correct? As an API consumer I find that design a bit confusing, what is the difference? Which one to chose? Would it be possible to have one of the two properties only?

@gappc the EventDocument property will become deprecated soon, for the moment we have to keep it since we have still some data consumer who are consuming data from it, but the plan is to mark it as deprecated within the next 3 months.

[ila131]

@sseppi @ila131 if I get this right, there are now 2 properties in the EventShort dataset that take care of documents, EventDocument and Documents, is that correct? As an API consumer I find that design a bit confusing, what is the difference? Which one to chose? Would it be possible to have one of the two properties only?

@ila131 if you want to work with the Documents property, you need to adjust the value for pathToParent in event.ts. Then you'll have to check if anything works as expected (e.g. upload).

Hey @gappc, thank you very much for your help, but how can I access the properties? Documents has a different structure than eventDocuments. By changing only the pathToParent into Documents, it does not read the properties.

[gappc]

@ila131 there was a bug in the language resolution for listFields. I've fixed it and improved the component in use.

Could you please take a look at it and check if it works as intended? If it's ok I'd go on and merge the PR.

[ila131]

@ila131 there was a bug in the language resolution for listFields. I've fixed it and improved the component in use.

Could you please take a look at it and check if it works as intended? If it's ok I'd go on and merge the PR.

Hey @gappc, thank you very much for your help but there is still an issue that if there are already some files uploaded, it does not read them. For example, for the following event https://databrowser.opendatahub.testingmachine.eu/dataset/raw/tourism/v1/EventShort/e98699d1-0ab0-4197-aa74-a9226d6e821c there are already some files in Documents but they are not displayed in the databrowser (see screenshot)

Let me know if it is clear, otherwise we could arrange a meeting.

[gappc]

@ila131 I think the problem is, that only the files for the current language are shown and there are no files for "EN" yet. If you change to e.g. "DE" or "IT" in the language picker, you should see the documents associated with that language.

I implemented the component to work that way on purpose, because the whole Data Browser works like this: you see the data for the current language. @sseppi should we leave it that way or should we implement a special handling for files?

[sseppi]

@ila131 I think the problem is, that only the files for the current language are shown and there are no files for "EN" yet. If you change to e.g. "DE" or "IT" in the language picker, you should see the documents associated with that language.

I implemented the component to work that way on purpose, because the whole Data Browser works like this: you see the data for the current language. @sseppi should we leave it that way or should we implement a special handling for files?

@gappc since there will be cases where the uploaded file will be different for each language, I would keep the behavior consistent with the whole Data Browser. Maybe for those files that are the same in all languages, we could implement a checkbox that if checked saves the pdf link in all languages. What do you think?

[gappc]

@sseppi i think the idea of checkboxes needs some further discussion as it is not immediately clear to me (the user?) how it works

[sseppi]

@sseppi i think the idea of checkboxes needs some further discussion as it is not immediately clear to me (the user?) how it works

@gappc OK, no problem... We can implement the checkbox in a second moment if needed.

[gappc]

@sseppi @ila131 is this PR now ready to be merged?

[ila131]

@ila131 I think the problem is, that only the files for the current language are shown and there are no files for "EN" yet. If you change to e.g. "DE" or "IT" in the language picker, you should see the documents associated with that language.

I implemented the component to work that way on purpose, because the whole Data Browser works like this: you see the data for the current language. @sseppi should we leave it that way or should we implement a special handling for files?

I see, thank you very much for the clarification. The PR can be merged from my point of view.