This is the purpose of getting the code and building them right? Contributing code!
Step-1: Search for tickets in JIRA:
- Start looking for tickets in this link, it provides a list of introductory tickets.
- Otherwise ,as an initial guide you can go through these specifications to browse through the tickets. Assignee – unassigned , Status- Ready for Work and Complexity – Low /Medium.
- Read the ticket description and if you feel that you understand even some part of it,then you can start working on it.
- It’s better if you can work on some UI issues as they will be mostly easy and get you going.
- So I can only give some guidelines about how to select but, ultimately you select the issue you want to work on.
Step-2: Replicate the Issue in Demo and Local Server:
- First thing you need to do after you select the issue is you replicate the issue i.e. go to the demo server and see if the issue exists. Mostly many important modules are also all added in the demo server for you to try them out. If you can replicate the issue then you have completed the initial part of solving the ticket.
- Even if you are able or unable to replicate the issue in the demo server the next thing to do is try replicating the issue in your local server. If you cannot replicate it then make sure that the version specified in the ticket is where you are trying out in your local server.
- In demo server we cannot add new modules, so if your issue is in such modules then you have to try it out in your local server itself.
- If you are unable to replicate the issue then you can put up a comment in the issue that you were unable to replicate the issue and ask if the issue is resolved.
Step-3: Claim the Issue:
- If you were able to replicate the above behavior and are ready to start working on the issue then click on claim issue and the issue will be claimed on your name.
- Now you can start working on it.
Step-4: Find the cause and make changes:
This is a process where I cannot help you much with as this is the purpose of the issue and each issue is unique.
But, I can provide you with some tips that can help you with working on them.
- Firstly, when you can locate the issue in a page in OpenMRS then you have the url and hence the page where the issue is existing.For Ex: if the problem is in patient dashboard page then the url will be something similar to http://demo.openmrs.org/openmrs/patientDashboard.form?patientId=7280&phrase=john
- “http://demo.openmrs.org/openmrs/” will be common for every page so this can be discarded. The values after “?” i.e. “patientId=7280&phrase=john” are data being sent to the page so even they can be ignored.
- The remaining part is the page i.e. patientDashboard.form. So when you search for a resource in eclipse (ctrl+shift+r) and type in patientDashboard you will find a jsp that is patientDashboardForm.jsp. So, this is the jsp responsible for rendering the webpage on the server.
While selecting a resource, you will see multiple files with the same name, but their path’s will be different. Always select the resources that have the path starting with openmrs-api , openmrs-web,openmrs-webapp instead of ones in path starting with openmrs/api , openmrs/web,openmrs/webapp.
I divide the issues into two types, issues involving changing java code and issues not involving changing java code.
Issues NOT involving changing java code:
These are the easy ones and testing them is even easier.They will be changes in view elements like jsp,js,css and they wont be requiring you to restart the server after every change.
- Go to “apache tomcat (version) > webapps>openmrs>WEB-INF” folder and search for the jsp file in it. Open your file in some text editor(It would be better if in a editor suppoting jsp/js/css files).
- Now while the server is started and when you save changes in the editor , you can just refresh the webpage and you will see the effect of your changes in the webpage.
Issues involving changing java code:
For these types of changes, you will need to build the war and replace the war and openmrs folder in tomcat webapps and restart the server each time.
- Now for finding out where the code change is happening, if you have the page then you can find it’s controller because it will be named after the page itself.
- So, when you find the controller if you don’t understand what exactly is happening, just put a lot of breakpoints and start the server in eclipse in the debug mode. Once you start it in the debug mode you can see when a breakpoint is hit while traversing through the webpage.
- You can look what all is happening like the variable transition , where the methods are going etc. Be sure to debug a lot!
- If you change any java code, then make sure that no test is failing because of your code change.
- After you make changes and would like to see the effects you need to build a new war, stop the server, delete openmrs war and openmrs folder in tomcat>webapps folder and copy the newly generated war into this folder and again start the server.
Step-5: Commit changes, keep a pull request and code-review:
If you are confident that your changes are correct and working perfectly fine, then follow these steps
- Get all the latest changes to your master from OpenMRS main source code by git pull –rebase upstream master.
- After you get the changes make your changes commit them, push them to your remote repository and keep a pull request.
- IMPORTANT: Make sure that only your changes are shown in green and only your deletions are shown in red any extra additions and deletions like a line being deleted and being added will not be accepted!
- If your changes have any functionality in view then you must take the screenshot of them and include them in the issue.
- Click on Request Code review and include your pull request url in the comment.
Step-6: Keep a track of your tickets:
- After you click on code review , people will review it and suggest changes, please do follow them and implement those changes.
- Until your ticket status is closed you are responsible for it. If you can no longer work on the ticket please un-assign yourself from the ticket, otherwise it would be an unnecessary task for openmrs developers to find these tickets and would leave a bad impression.