Skip to content

(feat) O3-4315: Add support for workspace-launcher rendering type #410

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

rdwaynedehoedt
Copy link

@rdwaynedehoedt rdwaynedehoedt commented Mar 1, 2025

Requirements

  • This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
  • My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
  • My work includes tests or is validated by existing tests.

Summary

This PR implements the workspace-launcher rendering type for form questions as specified in O3-4315. The workspace-launcher allows form creators to add buttons that launch different workspaces or sub-forms within the OpenMRS application, enhancing clinical workflow integration.

The implementation includes:

  • A new workspace-launcher.component.tsx component with input fields for buttonLabel and workspaceName
  • Updates to the QuestionOptions interface in types.ts to include these new properties
  • Registration of the component in the inputs index and component map
  • Integration with the existing form builder architecture

This feature is part of the O3 Form Builder v3 epic (O3-1144).

Related Issue

https://openmrs.atlassian.net/browse/O3-4315

Other

The workspace-launcher rendering type follows the specified JSON structure:

"questionOptions": {
  "rendering": "workspace-launcher",
  "buttonLabel": " ",
  "workspaceName": ""
}

@rdwaynedehoedt
Copy link
Author

Hi @NethmiRodrigo , could you review this PR Thanks!

Copy link
Contributor

@Bharath-K-Shetty Bharath-K-Shetty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rdwaynedehoedt Please add a video demonstrating that everything still behaves as expected & add unit test covering this change.

Copy link
Collaborator

@NethmiRodrigo NethmiRodrigo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rdwaynedehoedt! Good work! Please look at the comments and include a screenshot of the UI and how it works in the description. Its also preferred to add unit tests for new functionality, similar to how the other inputs do.

Copy link
Collaborator

@NethmiRodrigo NethmiRodrigo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there @rdwaynedehoedt! Some minor changes. Excellent test cases!

… callback pattern - Remove unnecessary test setup - Use userEvent instead of fireEvent in tests
@NethmiRodrigo NethmiRodrigo changed the title O3-4315 : Add support for workspace-launcher rendering type (feat) O3-4315: Add support for workspace-launcher rendering type Mar 17, 2025
Copy link
Collaborator

@NethmiRodrigo NethmiRodrigo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rdwaynedehoedt! One last thing :)

await user.clear(workspaceNameInput);
await user.type(workspaceNameInput, newValue);

expect(mockSetFormField).toHaveBeenCalled();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good to have, but we can make it a bit better by checking if it got called with the right object. Here's a place where you can use for guidance -

// Gets all calls made to our mock function, the arguments from the first call and the first argument of the first call
const updateFn = mockSetFormField.mock.calls[0][0];
// Execute the update function with the previous state
const resultState = updateFn(formField);
// Check that the result has the expected values
expect(resultState).toEqual({
...formField,
datePickerFormat: 'calendar',
questionOptions: {
...formField.questionOptions,
concept: '456',
},
});

@NethmiRodrigo
Copy link
Collaborator

Pinging @rdwaynedehoedt, are you stuck on any part of updating the tests, if so do let me know and I'll try to help out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants