Fix/update collection dto partial

[AnneGerlach]

What this PR does / why we need it:

• This PR relaxes the typing of the UpdateCollection use case to allow partial collection updates.

• Native Dataverse collection updates do not require a fully populated object, only the fields to be changed need to be provided.

• This change aligns the client typing with that behavior and avoids unnecessary TypeScript warnings in downstream usage.

• This is a typing-only change with no runtime impact.

Which issue(s) this PR closes:

• Closes -

Related Dataverse PRs:

• Depends on -

Special notes for your reviewer:

• TypeScript typing change only (Partial)

• No API or runtime behavior changes

Suggestions on how to test this:

Is there a release notes or changelog update needed for this change?:

• Yes, small changelog entry

Additional documentation:

[ChengShi-1]

Thank you for the change and your contribution. This is a good point. I tested the native api, and it does support partial updates.

However, I think we may need to do more tweaks, if we want to change it to "partial". createCreateOrUpdateRequestBody() is currently written for create/full-update semantics. Also, the current frontend code and tests also rely on full-update semantics. If we want to support partial updates, we will likely need broader changes across the DTOs, request-building logic, and tests, since the current design is aligned around full replacement.

[ekraffmiller]

Thanks for the PR, it would be a good addition to allow this, since it is allowed on the API.
I agree with @ChengShi-1, the current implementation of createCreateOrUpdateRequestBody() needs to change, to allow for partially populated DTO. Also, a test to show that it update is successful with a partially populated DTO. With those changes, I think it could be merged.

[AnneGerlach]

Thanks for the feedback! 🌻
I updated the implementation accordingly.

• updateCollection now accepts Partial<CollectionDTO>
• introduced a dedicated createUpdateRequestBody() for partial updates
• kept createCreateOrUpdateRequestBody() unchanged for create/full-update semantics

For the update case, only explicitly provided fields (!== undefined) are sent, so omitted fields remain unchanged.

The metadataBlocks logic now follows the Dataverse API semantics:

• only included if relevant fields are provided
• inheritance flags (inherit...FromParent) are respected and prevent conflicting fields
• avoids invalid combinations (e.g. metadataBlockNames + inheritMetadataBlocksFromParent=true)

(see: https://guides.dataverse.org/en/latest/api/native-api.html#update-a-dataverse-collection)

I also added partial update coverage in both:

• CollectionsRepository.test
• UpdateCollection.test

Optional: I did not rename createCreateOrUpdateRequestBody() to avoid additional overhead in this PR, although a name like createCreateRequestBody() would be more precise semantically.

[ChengShi-1]

Looks good! Thank you for the changes, Anne.

[ChengShi-1]

Could you also fix the integration error?

FAIL test/integration/collections/CollectionsRepository.test.ts (62.014 s)
  ● CollectionsRepository › getCollectionItems for published tabular file › should return collection items given a valid collection alias

    expect(received).toBe(expected) // Object.is equality

    Expected: "test-file-4.tab"
    Received: "test-file-4.tsv"

      1013 |       expect(actualFilePreview.fileType).toBe('Tab-Delimited')
      1014 |       expect(actualFilePreview.md5).toBe(expectedFileMd5)
    > 1015 |       expect(actualFilePreview.name).toBe(expectedFileName)
           |                                      ^
      1016 |       expect(actualFilePreview.publicationStatuses).toContain(PublicationStatus.Published)
      1017 |       expect(actualFilePreview.sizeInBytes).toBe(137)
      1018 |       expect(actualFilePreview.url).not.toBeUndefined()

      at test/integration/collections/CollectionsRepository.test.ts:1015:38
      at fulfilled (test/integration/collections/CollectionsRepository.test.ts:5:58)

[AnneGerlach]

Could you also fix the integration error?

FAIL test/integration/collections/CollectionsRepository.test.ts (62.014 s)
  ● CollectionsRepository › getCollectionItems for published tabular file › should return collection items given a valid collection alias

    expect(received).toBe(expected) // Object.is equality

    Expected: "test-file-4.tab"
    Received: "test-file-4.tsv"

      1013 |       expect(actualFilePreview.fileType).toBe('Tab-Delimited')
      1014 |       expect(actualFilePreview.md5).toBe(expectedFileMd5)
    > 1015 |       expect(actualFilePreview.name).toBe(expectedFileName)
           |                                      ^
      1016 |       expect(actualFilePreview.publicationStatuses).toContain(PublicationStatus.Published)
      1017 |       expect(actualFilePreview.sizeInBytes).toBe(137)
      1018 |       expect(actualFilePreview.url).not.toBeUndefined()

      at test/integration/collections/CollectionsRepository.test.ts:1015:38
      at fulfilled (test/integration/collections/CollectionsRepository.test.ts:5:58)

I reran the integration tests locally.
All CollectionsRepository.test.ts tests pass on my branch, so I wasn’t able to reproduce the error (either when running the test in isolation or as part of the full integration suite).

I do see other integration test failures in DatasetsRepository, but those also occur on develop for me, so they seem unrelated to this change.

Full test suite:

Test in isolation:

Could you also check this locally on your side?

[ChengShi-1]

Hi Anne, I was able to reproduce the error locally when using an outdated Dataverse version. After updating to the latest dev branch, the issue no longer occurs. Since the GitHub check is still failing, it might be running against an outdated version. I’ll re-run it later to confirm