feature: "project downloadattachments" / "bom uploadattachments"

[gernot-h]

I currently have the task to synchronize projects' attachments between two SW360 instances.

In my specific case, certain projects including source attachments are uploaded into two different instances, but clearing results (e.g. reports and CLI files) are uploaded in only one of them. So the remaining bit for me would be to download those from instance A and upload it to instance B.

So my idea would be to add following two commands:

    bom
        UploadAttachments    upload all attachments described in a BOM e.g. created by "project DownloadAttachments"
   
    project
        DownloadAttachments    download all attachments (of certain types) and create a BOM listing them

This would require extending the BOM formats by some fields, probably something like

 "externalReferences" : [
   {
    "type": "other",
    "url": "file:///attachments/CLIXML_keyutils_1.6-6-debian-combined.tar.bz2_2019-10-10_10_02_52.xml",
    "comment": "component license information (XML)"
    }
  ]

Alternatively, I could also implement "project uploadattachments", but I think with the suggestion above, it could be used flexible for multiple use cases.

Together "project createbom", "bom map" and "bom createcomponents", I think we could even support complete project export/import use cases in the future like:

• sync projects between different SW360 instances
• archive projects from SW360 to other systems
• migrate projects between SW360 and other platforms

What do you think?

[gernot-h]

This would also include a refactoring of "project getlicenseinfo" as this would mostly be a specific case of "project downloadattachments" then plus the HTML creation bits.

[gernot-h]

Still thinking what would be the most flexible user interface. Initial idea of Thomas and me was to offer "project DownloadAttachments" and "project UploadAttachments".

However, I think this is rather unflexible as you would always need a project to do downloads and uploads. As described above, I think offering "bom uploadattachments" might allow more use cases as you could update arbitrary releases and wouldn't require a project to do it.

And, thinking this through to the end, I should perhaps just implement "bom DownloadAttachments" and "bom UploadAttachments". We anyways have "project CreateBom" for getting an inital bom to operate with.

[gernot-h]

Given that we want to stay with the "project createbom" followed by "bom downloadattachments" approach, I looked into https://cyclonedx.org/docs/1.4/json/#externalReferences_items_type to decide how to add info about CLI files and clearing reports to BOM and I think I will go with an external reference of type "other" with according comments.

[SUMITKC1]

Hi @gernot-h,

This is a very thoughtful direction — using "bom downloadattachments" and "bom uploadattachments" sounds much more flexible than locking attachment actions to project scope.

I’d love to contribute to this feature, especially around:

Extending the BOM format to include externalReferences of type "other" for attachments like CLI files or clearing reports.

Implementing bom uploadattachments to support syncing artifacts between instances (e.g. from a BOM generated by project createbom or bom downloadattachments).

Adding helper filters (e.g. by attachment type or tag) if needed during download.

It would be great to align on the expected JSON structure and CLI interface design before starting. Once the format and command structure are finalized, I’d be happy to help implement and test the functionality.

Would you be open to me drafting an initial structure or CLI handler for bom uploadattachments?

Thanks! 🚀

[gernot-h]

@SUMITKC1, if you check the history of this issue, you should see that I started working on this quite a while ago in #33 (last update shown directly before your comment).

So if you want to support here, the most useful thing for now would be if you would have a look on my changes in #33 and provide some review. But as already mentioned in #142, I think this would only make sense if you (are planning to) use this feature of CaPyCli and have a clearing understanding of its implications.