Store, manage and display legal docs separately from the main asset files

[stijnvermeeren-swisstopo]

Currently, only one type of asset-file relationship is implemented in the application. This relationship is used both for the actual geological documents, as well as for the legal consent documents. In the database schema, this relationship is represented in the asset_file table, which only has two columns: asset_id (a foreign key to the asset table) and file_id (a foreign key to the file table). This has several disadvantages:

• Ideally, we would like the legal docs to be accessible/visible only to a restricted set of (internal) users.
• In the user interface ("Detailinformationen" for a specific asset), the legal docs should be displayed differently and less prominently compared to the actual content, so that the user can identify more easily which file is the one they are interested in.
• Automatic data processing pipelines currently have no way of knowing for sure which files should or shouldn't be considered for tasks like classification or language identification (the legal docs should generally be ignored for such tasks).

The database schema currently already contains tables legal_doc (with columns legal_doc_id, asset_id, title and legal_doc_item_code; empty as of September 2023) and legal_doc_item (with codes "contract", "federalData", "other" and "permissionForm" defined as of September 2023). These tables are not used anywhere in the application. It seems like these tables were already added to the database schema in anticipation of a feature similar to the one described in this ticket. However, money probably ran out before the feature was actually implemented.

ACs

• Database schema migration
  • Add an optional/nullable column file_id (with a foreign key that refers to the file table) to the legal_doc table
• Database data migration
  • All existing files with a file_name that ends with "_LDoc.pdf" should be classified as legal docs.
    • Add a new entry to the table legal_doc with
      • asset_id → read from the asset_file table
      • file_id → read from the file table
      • title → empty string
      • legal_doc_item_code → "permissionForm"
    • Remove the corresponding rows in "asset_file" for these files whose filename ends with "_LDoc.pdf"
• Application: view detailed information of asset
  • The legal docs (if any) should be displayed differently and less prominently compared to the main asset files.
  • Suggestion:
    • Add a new row "Legal consent" / "Rechtliche Einwilligungen" in the table, between the existing rows "Kontakte" and "Thema".
    • For every legal doc that is linked to the current asset, show a line with <legal doc type>: [<optional title>] [<filename> (<filesize>) <open in new tab icon> <download icon>].
      • For example: Permission form: a1004_1003_LDoc.pdf (1MB) <open icon> <download icon>
      • The part <filename> (<filesize>) <open in new tab icon> <download icon> can be reused from how the files / legal docs are currently displayed in the "File"/"Datei" row at the top of the table.
    • In the "File"/"Datei" row at the top of the "detailed information" table, only show those files that are still linked through the asset_file table (i.e. the legal docs are no longer shown here).
• Application: create/edit asset
  • Enable uploading/removing legal documents separately from the main asset files.
  • It should be possible to specify any number (0-unlimited) of legal docs for each asset.
  • Enable selecting the type ("contract", "federalData", "other" or "permissionForm") of each legal doc. This value must be set.
  • Enable specifying an optional title for the legal doc. This value can be empty.
  • Enable adding a legal doc without uploading any file. (This will be used primarily for the "federalData" type, but this should not be implemented as a formal constraint / validation rule.)

[vej-ananas]

Schätzungen
Frontend 2
Backend 2

[vej-ananas]

Fragen:

1. Derzeit besteht eine n..n Beziehung zwischen Asset und File - Ein Asset kann mehrere Files haben, mehrere Assets können dasselbe File haben. Wird dies benutzt? Was ist der Zweck davon?
2. Wofür braucht man ein LegalDoc ohne Dokument?

Enable adding a legal doc without uploading any file. (This will be used primarily for the "federalData" type, but this should not be implemented as a formal constraint / validation rule.)

[mPfifi]

@vej-ananas Sieht gut aus, der separate upload scheint auch geklappt zu haben.