prepend source UUID to external docs' file name

[okworx]

Issue

Currently, when external docs are stored in a ZIP file for export, they are simply written to the external_docs folder.

Now there may be collisions if a user uses the same file name for different external docs, which will cause a conflict during export. Consider the following example:

Source dataset A (UUID c50ec8b7-691d-458b-8379-a8d787e4e4b4)

• attached diagram for product system "electricity mix" (file name flow_chart.png)

Source dataset B (UUID 9bf38b43-d3f5-4f94-99b3-178531ea74bb)

• attached diagram for product system "process steam" (file name flow_chart.png)

When these datasets are exported to the file system, both files flow_chart.png will be written to the external_docs folder, one of them being overwritten with the other.

We can't simply circumvent this at export time by altering file names, since we'd also have to alter the reference in the corresponding source dataset in this case, which is not an option.

Proposed solution

In order to ensure non-ambiguous file names for external docs, in practice it has proven to be effective to append the UUID of the source dataset to the attached external docs. For the example above, this would look like this:

Source dataset A (UUID c50ec8b7-691d-458b-8379-a8d787e4e4b4)

• attached diagram for product system "electricity mix" (file name flow_chart_c50ec8b7-691d-458b-8379-a8d787e4e4b4.png)

Source dataset B (UUID 9bf38b43-d3f5-4f94-99b3-178531ea74bb)

• attached diagram for product system "process steam" (file name flow_chart_9bf38b43-d3f5-4f94-99b3-178531ea74bb.png)

Renaming the external doc file would have to happen by the application at the time the file is attached to the source. The user could be offered the option to use the original file name instead (if for example they are certain that the file name is and will always be non-ambiguous, for example if it already contains a UUID), but probably the described approach should be active by default.

This way, a collision could be avoided when exporting to a ZIP file.

This is not a critical issue but as the user base of the tool grows, this would be good to have in the mid-term.