Conversation
* Added new config option in dsf-maven-plugin to add a single E-Mail address to generated certificates: <email>...</email>
* Practitioner users now need to reference themselves as Task.requesters using NamingSystem http://dsf.dev/sid/practitioner-identifier as Identifier.system and their eMail address as Identifier.value. * Practitioner users with DSF_ADMIN role now have same Task (create/read/update) privileges as local organization users. * Task resources with status draft can be read by all practitioner users. * Task resources with status requested can be created by practitioner users if they have the needed role authorized by the associated ActivityDefinition. Practitioner users with role DSF_ADMIN can create Task resources with status requested if they are allowed for the local organization. * Modified Task UI (incl. JavaScript) to specify the practitioner eMail as requester. Main UI now shows the users roles and eMail as tooltip of the "Hello, ..." text. * New default eMail addresses for OIDC and certificate users without an explicitly defined value. OIDC will use the pattern <sub>.<iss-host>@oidc.invalid, certificate will use <sha512-thumbprint-hex>@certificate.invalid.
- QuestionnaireResponse resources can be read if local org user, DSF_ADMIN and practitioner authorized by extension - QuestionnaireResponse resources can be created by local org user and DSF_ADMIN - QuestionnaireResponse resources can be updated: - in-progress -> completed by local org user, DSF_ADMIN and practitioner authorized by extension - in-progress -> stopped by local org user and DSF_ADMIN - completed -> amended by local org user and DSF_ADMIN - QuestionnaireResponse resources can be deleted by local org user and DSF_ADMIN - Modified and new integration tests
- QuestionnaireResponseHandler now updates received completed QuestionnaireRespons resources to status amended, to make sure a out of sync BPE DB is not flooded with already handled resources on startup.
- Author and authored are now shown in the info-box
- DefaultUserTaskListener can now be configured via bpmn field injection using fields practitioner (for practitioner identifier), practitionerRole (for practitioner role coding), practitioners (list of identifiers, expression only) and practitionerRole (list of roles, expression only). In order to use field injections, dev.dsf.bpe.v2.activity.DefaultUserTaskListener needs to be explicitly specified as task listener Java class. But does not need to be registerd as prototype bean.
- The QuestionnaireResponse generated by the DefaultUserTaskListener no self declares the http://dsf.dev/fhir/StructureDefinition/questionnaire-response profile.
- Camunda engine requires code and message to be non null and non empty
- Added two practitioner users to the FHIR server role config with minimal Task/Questionnaire/QuestionnaireResponse roles - Added two client connection to the BPE server fhir client connections config - BPE client connection "dic-user" has practitioner role DIC_USER on FHIR server with identifier dic-user@test.org - BPE client connection "uac-user" has practitioner role UAC_USER on FHIR server with identifier uac-user@test.org
- Additional Questionnaire/QuestionnaireResponse tests check role and identifier authorization for updating (in-progress->completed) QuestionnaireResponse resources. Existing test checks update for the local organization user.
String list is serialized using java serialization to allow usage of the variable with JUEL expressions, e.g. when setting the value via a Field Injection and a setVariable(List<String>) method.
- New integration test checks setting multiple practitioner identifier via DefaultUserTaskListener field injection with a List of strings
issue/367_User_to_Task_and_QuestionnaireResponse_Association
schwzr
approved these changes
Oct 17, 2025
This file contains hidden or 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
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.
requestednow need to reference a practitioner using systemhttp://dsf.dev/sid/practitioner-identifierand the email address as value, if the resource is being created by a practitioner user. Meaning a local user that logs in using a client certificate or OIDC token, configured via role config. The behavior for local or remote organization users (authorized via allow-list) did not change.DSF_ADMINrole, now have the same access as local organization users.in-progresstocompleted.{ "resourceType": "QuestionnaireResponse", "extension": [ { "url": "http://dsf.dev/fhir/StructureDefinition/extension-questionnaire-authorization", "extension": [ { "url": "practitioner", "valueIdentifier": { "system": "http://dsf.dev/sid/practitioner-identifier", "value": "practitioner@organization.com" } }, { "url": "practitioner-role", "valueCoding": { "system": "http://dsf.dev/fhir/CodeSystem/practitioner-role", "code": "DIC_USER" } }, { "url": "practitioner-role", "valueCoding": { "system": "http://organization.com/fhir/CodeSystem/my-role", "code": "SOMETHING" } } ] } ], "status": "in-progress" }DSF_ADMINrole, now have the same access as local organization users. Update allowed behavior for local organization users not changed.completedtoamendedafter triggering the process to complete the associated user task.created. If configured the DefaultUserTaskListener creates the authorization extension.All modifications together allow process plugins developers to fully take advantage of local practitioner users with different roles.
closes #367