Hi All,
I am going to work on Facility Data Module. My work would include upgrading module to support openmrs 2.x , adding new fields and support for text , blob for the answer type etc.
I have few questions related to module.
I suppose I am the main maintainer of the module, though I don’t believe any of the implementations that PIH directly supports are currently using this any longer. As far as I know, no one is actively working on this. You can see the git commit history here.
There is a JIRA project here with a few still open tickets. It looks like you have found this as you are assigned to a few of them.
Do you have any direct needs you are developing for (eg. an implementation that you support that is asking for this) or are you just looking for available tickets to work on for the community?
Thanks for your support! Best, Mike
As you know OpenMRS is patient centric, but we want to save User related data also. For this , we discussed with other openmrs community for a solutions . you can see the discussion here. There were three different solutions suggested.
For us , Facility data Module seemed a good choice as it would reduce alot of our work but just to tackle our needs like compatibility with OpenMRS 2.x , some generalized fields like open text as a answer and etc . For this , I am going to work on this.
As far JIRA tickets go, Yes i have created some of them and going to work on them. There are something i wanted to discuss before going ahead with developement. Like Should i upgrade to liquibase in current version or first upgrade module to 2.x then upgrade to liquibase?
Thanks for your support! Regards, Muhammad Ahmed
@ahmed14, thanks for the information. It would be interesting to hear what changes you are proposing. The facilitydata module is not really designed to collect information at the user-level, but at the location level. From a data model perspective, it probably wouldn’t be too hard to alter this such that user was a further level of granularity below location, or an alternative to location, but from a UI and reporting perspective we would need to make sure that everything was aligned.
Regarding steps to upgrade, I would favor upgrading to liquibase first, but I’m not really sure it matters.
Mike
As far our needs, module should be Compatible with OpenMRS 2.x and later versions. As far as the development goes, I strictly make changes according to it. In Module, there are some minor changes, which will fulfil our requirements like • Saving Text type answers • Saving blob type answers • Saving Document type answer • Add provider option • Adding new Frequency type : Random (for forms which are not collected on regular or monthly basis)
If you have any suggest that could help me improve the module in better way, please do suggest.
I have started development, I have moved module from hibernate xml config to JPA annotation. I have encountered an issue with sqldiff.xml not being run. I didn’t wanted change sqldiff.xml as I read here that module will run sqldiff.xml first if there exists then after that It will run liquibase.xml . But it isn’t running sqldiff.xml in OpenMRS 2.1 . So I am little confused here what to do ? could you please suggest me.
Your suggestions will be very helpful. Thanks for your support. Regards, Muhammad Ahmed
I am thinking of creating a separate branch on GitHUb and sprint on JIRA for upgradation facilitydata module to 2.x . What do you think?
Thanks Muhammad Ahmed
@ahmed14, a branch is always a good idea for any new development, so I’d certainly support that. One approach would be for us to branch master off into a 2.x branch (the current version of the module is 2.6-SNAPSHOT), and leave this there so that anyone needing to maintain compatibility with OpenMRS 1.9-1.12 could add bug fixes and release new versions in the facilitydata-2.x line.
Then, you could update master to be version 3.0.0-SNAPSHOT which depends on the latest OpenMRS core version (or maybe 2.0).
If it helps to create a Sprint in JIRA then that’s fine with me - this is probably only really useful if there will be multiple people collaborating on this over a finite period of time though. If this is just you doing the work, and will work on it until it is complete, then a sprint is probably not adding a lot of value.
Mike
Branching off the master branch into 2.x branch would be great. This way i could work on module which can work only later to 2.x version. This would remove alot of compatibility work also.
Yes, I am the only one working on the module currently. But i think creating a separate sprint for 2.x would be good as i would give alot of idea and information to any other developer who may work on this later. As he can know what different works has being done on this. Its your call whether i should add sprint or not? if not , then i will start creating tickets on the same sprint and start working on them.
Thanks, Muhammad Ahmed
@ahmed14, whatever works best for you to manage the tickets and work for this project is fine by me. Do you need me to create this for you or do you have all of the permissions you need?
hi @mseaton ,
Sorry for late response. I started work quite early. it is almost complete. i haven’t created any tickets regarding the changes and new features. let me first write them down here for your understanding.
after completing the rest service, i would create a pull request. This will support from 2.x later OpenMRS versions.
Done. @owais.hussain / @ahmed14, first step should now be to update master poms to be 3.0.0-SNAPSHOT