Bump @pdc/sdk from 0.35.1 to 0.36.1

[dependabot]

Bumps @pdc/sdk from 0.35.1 to 0.36.1.

Changelog

Sourced from @​pdc/sdk's changelog.

Changelog for @​pdc/service

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

Unreleased

Fixed

• Bulk upload processing no longer fails when a row leaves a file-typed field blank. The empty cell is stored as a non-file value (value: "", isValid: false) and no attachment lookup is attempted for that field.

Changed

• Creating an entity now automatically grants the creator a manage permission with any scope on the new entity. This applies to opportunities, changemakers, proposals, sources, bulk upload tasks, application forms (and their fields), proposal versions (and their field values), and changemaker field values created via the HTTP API, as well as proposals, proposal versions, proposal field values, and newly inserted changemakers created during bulk upload processing.
• Viewing application forms now requires explicit view | applicationForm scope, checked via a new has_application_form_permission function. The scope can be granted at the applicationForm, opportunity, or funder context level and is inherited appropriately. Previously this was implicitly granted by any view | opportunity grant.
• Viewing application form fields now requires explicit view | applicationForm scope on the parent application form, checked via has_application_form_permission. Previously this was implicitly granted by any view | opportunity grant. Application form fields do not have their own independent permission scope; access to a field is determined entirely by access to its parent form.
• POST /applicationForms now requires edit | applicationForm scope on the target opportunity instead of edit | opportunity.
• PATCH /applicationFormFields/:applicationFormFieldId now requires edit | applicationForm scope on the parent application form instead of edit | opportunity.
• Existing permission grants with opportunity scope on funder or opportunity contexts have been migrated to also include applicationForm scope. This preserves prior access for grantees who relied on opportunity-scoped grants for application form access.
• /permissionGrants endpoints (list, read, create, update, delete) no longer require administrator role. Non-admin users holding the manage verb on a grant's context entity may now list, read, create, update, and delete those grants. GET /permissionGrants filters results for non-admins to grants whose context entity they can manage. Updating a grant requires manage on both the existing and proposed context entity.

0.36.0 2026-05-12

Added

• Permission grant responses now include a createdByUser field containing the full user entity, similar to what we've implemented for Bulk Uploads.

Changed

• Upsert endpoints now distinguish a created row from an updated one via the HTTP response status: a fresh insert returns 201 Created, while updating an existing row returns 200 OK. This applies to PUT /baseFields/:shortCode, PUT /baseFields/:shortCode/localizations/:language, PUT /changemakers/:id/fiscalSponsors/:fiscalSponsorChangemakerId, PUT /dataProviders/:shortCode, PUT /funders/:shortCode, POST /funders/:shortCode/members/:memberFunderShortCode, and POST /funders/:shortCode/invitations/sent/:invitedFunderShortCode. Previously each endpoint returned a fixed status (some 200, some 201) regardless of whether a row was inserted or updated.

0.35.0 2026-05-05

Added

• Added any to the permission grant entity type set. When any is included in a grant's scope array, that grant satisfies any scope check on its context (e.g., view | any on a funder context grants view access for funder-, opportunity-, proposal-, and proposal-field-value-scoped data on that funder, including scope types added in the future). any is also recognized as a context entity type for forward compatibility but is not yet accepted by the API as a context.

Changed

• GET /baseFields is now paginated in the same manner as all other GET endpoints. This is a breaking change. The endpoint can now take pagination parameters (_count, _page) and will return { entries , total } where entries is an array of base fields,
• The manage permission verb now satisfies any verb check on the scope to which it is granted. A grantee with manage on a given scope no longer needs the other verbs listed alongside it to perform view, create, edit, delete, or reference operations at that scope. Scope matching is unchanged: manage does not grant access to scopes that are not explicitly included in the grant.

0.34.0 2026-04-23

Added

• Add extension support in phone number validation.

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)