Welcome to our community, @shyam1ss15 and @parthis! I suggest that you take a look at and use our Guide for the New & Curious as a starting point for your OpenMRS journey. It will point you to our community conventions, give you a sense of how we’re organized, and link out to some active squads or teams working on projects that you might want to get to know better. Many squads and teams have specific guidance for getting started on their projects.
thank you for your guidance sir
Here’s an idea:
O3: Migrate forms to React Hook Form
- We currently have a bunch of forms written in O3 in vanilla React. These forms, though functional, are not the most performant or extensible and for the most part, lack validation. React Hook Forms offers easy-to-use validation out of the box, performance and tiny bundle size. The task is to refactor existing forms to use the React Hook Form library and Zod for schema validations. The forms that this refactor would target include:
- Start Visit form
- Allergy form
- Programs form
- Conditions form
- Visit Notes form
- Appointments form
- Vitals and Biometrics form
- Medication Order form
- Patient Registration (heaviest lift, written in Formik)
- Scope: Medium. Needs good knowledge of React, HTML, CSS and TypeScript.
Thanks @dennis for bringing this up. It could be a good idea to add it on our ideas list: Summer of Code 2023 - Resources - OpenMRS Wiki including the mentors of the project.
Hello everyone! Here’s my idea proposal.
GSoC 2023: Extending E2E Automated Tests for the OpenMRS 3.0 RefApp
The Microfrontends Team has created a new Reference Application, the “3.0 RefApp”, which represents the future of OpenMRS. It features a modern Microfrontend architecture and replaces the previous “2.x RefApp”. Students who excel in the end-to-end (E2E) testing of this project may also have the opportunity to contribute to the frontend widget and feature development for 3.0. This is because E2E testing will familiarize them with the 3.0 codebase and there is a high demand for feature development.
At present, there are already a few E2E tests running for the openmrs-esm-patient-management repository and more coverage is expected. The goal of the project is for someone to extend the E2E tests for openrms-esm-patient-chart and openmrs-esm-core using the Playwrite framework. The tests will be set up to automatically validate the user interface based on specific workflows.
- A fundamental knowledge of OpenMRS Microfrontends is required.
- Proficiency in frontend web development, particularly with React, is highly desirable.
- Prior experience with the Playwright framework is a plus, although the ability to write 1-2 simple test cases with it is sufficient. The rest can be learned during the project.
Overall Goal: Set up tests that automate realistic User Workflows for openrms-esm-patient-chart and openmrs-esm-core and show the squad the results, with a warning indicator on a shared Repo ReadMe so that no one misses failing tests.
- The smoke tests are organized according to user workflows, reflecting a user’s perspective.
- A limited number of E2E tests are performed on the happy-path user stories (when everything goes smoothly).
- These tests do not cover every possible interaction or scenario. Detailed functional tests, which are beyond the scope of this E2E Workflow-based draft, are responsible for that.
- Consider the transitions between different parts of the application, managed by different Microfrontends, when developing these tests.
- Our goal is for business-level users to easily understand the extent of functionality coverage through reports like this, and to quickly identify areas that may need improvement.
Hi all, here’s another project idea:
GSoC 2023: An effective unit & integration test strategy for OpenMRS3
OpenMRS consists of several micro frontend modules and repositories, most of which have unit and integration tests written by individual developers. However, these tests exhibit inconsistencies due to the diverse testing strategies used by different developers. To address this issue, there is a need for a consistent and comprehensive test strategy or framework for the unit and integration tests of OpenMRS3, aimed at achieving a high level of test coverage.
Implementing an effective unit & integration test strategy for OpenMRS3.
- Develop a comprehensive testing strategy that can be applied to all OpenMRS3 micro frontends.
- Determine what to test (e.g. In react → props, state, rendering, event handling, error handling)
- Specify testing method (e.g. libraries, mocks, stubs)
- Ensure test coverage (e.g. edge cases, positive and negative scenarios)
- Document the strategy
- Outline the necessary tests based on the strategy (including a draft for a single repository in the project proposal)
- Upgrade existing tests to align with the new strategy
- Implement any missing tests
- Resolve any bugs in the current tests.
Further improvements (Optional):
Improve the code quality testing mechanism (ex: eslint)
Familiarity with OpenMRS microfrontends (including setup and directory structure) Background in microfrontend development Proficiency in testing techniques
A robust, well-documented unit and integration testing strategy for OpenMRS3 microfrontends To be used as a reference by developers in future development efforts.
Note: Since we have enough time before the GSoC student application period, we can introduce the test strategy by ourselves and make the project more focused on test coverage instead of the test strategy. Editable doc: GSoC 2023: An effective unit & integration test strategy for OpenMRS3 - Google Docs
@piumal1999 which test strategy have you thought-of would work best for our o3?
/cc: @dennis @vasharma05 @ibacher
O3: Validating and re-working (update and upgrade) OpenMRS PatientFlags module
I raised a PR adding patient-flags into RefApp 3.x as an initial task for the ANC prototype but merging is blocked for now because the backend module is not-worthy.
As a matter of fact, I personally had to do some tweaks with this module for successful getting of the flags from the backend.
@jnsereko Thanks for this work. We’re going to hold off on merging this for right now not because the frontend part is in any way not what is called for in the designs, but because I think the backend module needs to be re-engineered before it’s ready to be integrated into the RefApp. In particular, I want to be sure that it performs well enough. Once we have that added to the RefApp, we can merge this PR in. (PS Validating and re-working the backend module for this would be an excellent GSoC project…)
In addition, we can actually also include some other ANC prototype tasks to the project, both frontend and backend.
I have come up with some improvements for the O3 form builder that I believe could enhance its functionality. These include
- Reference forms
- Ability to edit answers (Same as Ampath)
- Ability to edit concept mappings (Same as in Ampath)
- Ability to rearrange questions (This was suggested by Grace, where the user can rearrange the questions by dragging)
However, these improvements may not be sufficient for a 175-hour project, and I am open to any suggestions for further enhancements.
As I will be on vacation this summer, I’m interested in mentoring a GSoC project this year, if possible. I am particularly interested in the following projects
- O3: Draw on a Body Diagram
- O3: Migrate vanilla React forms to RHF
Thanks for your interest in becoming a mentor @kumuditha!
@dennis, do you have any suggestions on how to turn the form builder into a GSoC project? Alternatively, do you have a specific project in mind that Kumuditha could mentor?
I looked into O3: Draw on Body Diagram project idea and I think if we can scope it down to mark certain areas of an upload diagram – either with a certain shape, or a single point – and provide support to it with a data structure that can facilitate those meta data we’ll have a well scoped idea for medium sized project. Storing an array of x, y coordinates with the description will be a simple way of achieving this goal, This way we will be able make nice looking and interactive diagrams. There could be different ways like storing them within the digram itself through vector files too. We can put the dynamic drawing as an optional objective of the project and extend the basic implementation to include them later on.
I think a good proposal for this project should include,
- A good requirement analysis
- A good explanation on how to handle different image types
- Good data structure design to store diagram meta data
- Plans on,
- How to handle the diagram upload and store
- How to handle the editing of the diagram on the frontend
- How to render those diagrams properly with the edits
- Set of wireframes for the UIs
- The list of API endpoints that is needed to support those UIs
Even though I won’t be able to write proposal myself since I’m working as a full time SE, I’m very much interested in getting involved in this project to help out whoever that wants to submit a proposal for this idea or even mentor the project if needed.
Thanks @heshan for jotting down these interesting insights. i see this coming to life @grace @jennifer
Have made a few use case scenario suggestions i think it folds in to rump-up a good SRS at this point in time.
I think @heshan we can work together to get this done perfectly. Will be glad to take this on.
I’m also interested in 03: Responsiveness & Tablet-based Needs for OpenMRS 3 project. The main objective of this project is to make the responsiveness of the application consistent throughout devices. Since OpenMRS 3 is developed on Tablet first, I couldn’t be able to find many issues on the tablet view in the patient chart. But we can improve the responsiveness in other modules in the application such as Fast Data Entry, Corhort builder and Form builder.
Here are a few more suggestions
Ensure that the layout is optimized for laptops, tablets and other screens. More information: https://v9.carbondesignsystem.com/guidelines/grid/design
Optimizing the code for better performance. Remove unused code, and optimize loops and conditions.
Test the application on different devices with different screen sizes, and resolutions to ensure the interface is responsive and functions properly on all devices. This will help us to identify more bugs in the interface.
Here are a few things that I think a good proposal should contain.
- Requirement gathering (Identifying bugs/issues)
- Identified issues in Tablet-based screens
- Identified issues in Laptop screens
- Implementation plan for
- Tab based responsiveness
- Laptop based responsiveness
- Wireframes depicting the designs
What do you folks think?
I would love to help make it a success by offering my assistance as a mentor or in any other way. Please let me know how I can be of help, as I am enthusiastic about contributing to this project in any way possible.
Hey @kumuditha ! Interesting capture of the project needs and requirements. Just want to clarify, are you interested to contribute as a developer contributor or as a mentor?
Hey @vasharma05, I’m interested in becoming a mentor.
User Onboarding got my interest. Can anyone help me to gain access to the design cc @jayasanka @kdaud
is this channel for contributors too? I am just a beginner here so asking, sorry for interrupting.
@kartikaysaxena we are glad to have you join the community. Checkout Guide for the New and Curious - Documentation - OpenMRS Wiki
Hi @dennis I am much interesting in workin gon this project. In simple terms the project requires migrating the forms from vanella react to reack hooks which enhance better functionality. Can I create a project topic on the openmrs so we discuss the idea more there or which other way is the best.