Release 1.2.0 #470
Merged
Release 1.2.0 #470
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The new version seems to require IntelliJ 2023. And, as usual, the JS facades had to be updated; `serializer()` access through companion objects now also seems garbled, but luckily always to `.o14()`, so I could add a new facade to access serializers.
Although there is a later version of `@typescript-eslint/typescript-estree` available, using any later version will require updating to a newer module resolution than "umd": typescript-eslint/typescript-eslint#7284
Warnings are now treated for all compilations, also test compilations, for which two fixes of missing `@Target` attributes were added. And, refactored warning configuration to be centralized in a single place.
This makes it clearer that the protocols subsystem primarily provides management of protocols, whereas a lot of the protocol building blocks are in fact defined in carp.common. In addition, this emphasizes separation of data among studies, deployment, and data subsystems.
The properties `id`, `createdOn`, and `version` of snapshots couldn't be accessed through JS/TypeScript since they were defined on a base `Snapshot` interface which couldn't be JS exported from Kotlin due to an unsupported `Instant` type. But, by suppressing a warning the base `Snapshot` interface can in fact be exported, and the resulting TypeScript code compiles since the custom build pipeline already modifies generated TypeScript sources to support `Instant`.
`ts-node` and `jsdom` seem to be no longer needed when running mocha tests.
Also updated other JS/TS dependencies. Primarily, updating to nodenext also allowed to finally upgrade `@typescript-eslint/typescript-estree`, which depended on this module system.
Later more strict JS module systems require package.json to be present.
Without these, projects using the output modules did not automatically pick up the typescript declarations.
Currently, there was no coverage for adding custom participant attributes to protocols in the backwards compatibility tests. The test resource also serves as an example on how such a JSON request looks like, which was a request in #451.
The previous functionality verified whether a matching `ApplicationServiceRequest` class was defined per application service request by matching class names to method names. This is ambiguous in case you want to overload application service methods, and map them to different request classes. Instead, a request object instance can now validate whether it matches a given request method, which allows it to validate the full method definition. The default implementation relies on name matching like before, but it can now be overridden. Since a check is made an example request is available for each application service request, this still fully validates a request object is available per application service request.
This simplifies modifying the class discriminator for JSON objects.
This includes a `RecruitmentService` API upgrade and a migration to convert `RecruitmentService.AddParticipant` requests into `RecruitmentService.AddParticipantByEmailAddress` requests.
xelahalo
approved these changes
Mar 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This release helps implementing infrastructures (specifically CAWS) to implement web-based studies with anonymous participant invites. The underlying mechanism to do so is not different from "username" identification/authentication of users. The username simply needs to be an anonymous ID generated by the infrastructure, and the infrastructure can pass the username/password to the user using their preferred mechanism (e.g., embedded in a one-time link).
These changes require no database migration. If a relational database was used to store
AccountIdentity(instead of a document store simply storing the serialized JSON), you may need to add support to storeUsernameAccountIdentity, although this type was already defined before this release.In addition, improvements to JavaScript sources and TypeScript declarations:
Nullable(Some extra documentation and Nullable TS export #445)Dependency updates:
Subsystem changes
Common
Websiteprimary device (Add Website as a device #465)Studies
RecruitmentService.AddParticipant()overload which accepts users that are identified by a username (Allow adding participants by username inRecruitmentService(#459) #467). The existingAddParticipantrequest object was renamed toAddParticipantByEmailand the new method was added asAddParticipantByUsername.