Proposing a sprint to help people upgrade to Platform 2.x (Mozambique tried to upgrade to Platform 2.x, but was blocked for various reasons)

@achachiez, it would be great if you can share more about your experience!

If we do this sprint after beginning of May, some of the Mozambique eSaude team can join in. @valvijo @ningosi @carina @yassin @hmutaquiha @minoneves - what do you all think?

We can set the timing for this as needed to maximize who can participate, and it would be great if a team that actively would like to upgrade to Platform 2.x is participating! (Can you give more clarity about what “after the beginning of May” actually means?)

Any other groups and individuals interested in participating?

I would suggest that if you generally want to upgrade to the latest OpenMRS Platform releases, you would do well to schedule trying to do this simultaneously with others on this sprint, so that we can identify, analyze, and fix any upgrade issues quickly with everyone focused on it.


I am starting to create/collect tickets for this sprint (and I created a label in JIRA: help-upgrade-platform-2):

  • TRUNK-5383 - Automatically handle upgrading data model to 2.0 even when the reporting module is installed
  • RCM-106 - Patient searches return 0 results on platform 2.1
  • TRUNK-5384 - Use new Implementation ID server URL, and support redirects and https in our custom HttpClient class

@ningosi there are some things I want to confirm with you:

Still to do:

2 Likes

I am interested and I want to participate even though I have done an upgrade several times with the help of @dkayiwa, also I have prepared a brief documentation of upgrading process and challenges I have encountered together with specific solutions. I can send this document If you think it can be of some help.

3 Likes

The patient flag rest module is the custom module for esaude that extend patient flag module for reporting on our POC which is javascript front end, for this to work on 2.x we just need a release of patientflags module that is NOT depended on logic module.

Yes. the form filter module is this one, as you have highlighted.

And as @janflowers puts it, it will be good for the testing candidates to be included in the whole process of upgrade planning.

This will be helpful for us to participate fully. We might contribute items that will help to improve the product for other implementers to ride on.

1 Like

@ningosi Why not just integrate the eSaude REST code into the patient flags module (which already runs on 2.x) so that you do not need an extra module to maintain?

@janflowers @valvijo @ningosi @carina @yassin @hmutaquiha @minoneves

  1. What additional functionality does Mozambique implementation have that can be brought back into the OpenMRS Reference Application main line

  2. Can you provide a comprehensive list of blockers that can be considered

  3. Please can you join the Reference Application 2.8 planning design call tonight as we seek to prioritize what can get done in this release, any spill overs go to the next release.

@ningosi I have just landed on this now, in UgandaEMR we can store numeric concepts with a decimal point - is it the concepts that you mean here?

“After the beginning of May”: We are finalizing a release of a point of care module in April. Once we complete that release, one of the next high priority items for the Ministry of Health in Mozambique will be to add the ability for synchronization, as the national architecture will utilize both a centrally hosted server and some local district or facility hosted servers that will need to by synchronized with the other data. So we will need to start working on this in May and June. Does that help?

1 Like

I think it would make a lot of sense to anchor this sprint around the eSaude team’s availability. (We can tackle some issues earlier, of course.) So, @esaude, can your team propose some dates that would work for you all? (E.g. is the week starting May 7 too soon?)

@Others, it would be great to have 1-2 more implementations that try to work on an upgrade together as part of this sprint, so please do speak up if you’re interested too.

Okay, it looks like this (unreleased) commit from November should address that issue, so hopefully we just need to do the release. (It could be nice if you can merge in your REST code at the same time, so you can just use the mainline module.)

@jmkumbo Great! We’ll be looking for people to participate in several ways, both during the eventual time we schedule, and leading up to that.

Please do share the document.

The week of May 7 is perfect for eSaude, right in the interval between two big activities.

2 Likes

@achachiez Can you contribute the patches back to the community, also can you share those modules you failed to patch for us to prioritize them

@darius The source of this document is from openmrs documentations and from my experience during implementation process, I think it is usefully for a newbie. Upgrading and Installation process.pdf (345.7 KB)

Thanks @valvijo. Do you think that someone from your team can join the OpenMRS Project Management call on Monday (I think it’s 5pm in Mozambique) so we can work out a few planning details?

@darius from my team the following will join the call: @ningosi, @jsibley and @valvijo. Thanks

1 Like

@darius Am solo ,can i join the sprint if am not in a team? I just created https://issues.openmrs.org/browse/DATASTATS-3 in response to As historic "core devs" move on, where do we go from here?

Of course @tendomart!

The idea is to bring together some implementation teams that want to do an upgrade (at least the eSaude team for now) and volunteers who can help provide extra dev power to make this happen, so we definitely want individual participants.

I appreciate you taking the initiative. Actually, see this post of mine (#15 in this thread) where I mentioned both tickets I have already created (this JIRA query) and some things that are still to-do in order to decide whether to create tickets or not.

You can either start on the already-created tickets, or else help with some of the To Dos to determine whether/how tickets should be created. For example for the ticket you created, Nicholas did his testing in November/December (I think) but Stephen says it works for METS, so either (a) it was fixed/released after Nicholas’s testing, (b) something about the esaude config is different, (c ) Nicholas just made a mistake. In this case you could try setting up a clean installation of latest OpenMRS with the SDK, and then adding this module, and seeing what happens.

can i also still join the team ? or its already late :thinking:

1 Like

You can definitely join. Here is the current discussion of the sprint: "Help People Upgrade to Platform 2.x" Sprint Announcement

Here is the sprint board: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=160&view=detail

Otherwise, @darius can point you to the issues he is tracking that have come up.

1 Like

thanks @janflowers