OpenMRS Platform 2.3.0-beta released for testing

ruhanga · October 31, 2019, 6:08pm

Hi all,

I think it’s okay taking forward the Platform 2.3.0 full release. I and @tendomart have made a number of tests with the Reference application distribution built on top of the beta version. I have tested the rest endpoints using the default demo data and I think we are good to go. A couple of more commits on the platform are probably also on their way due to the on-going work on the Data filter module. Do we want to rather give more time to include the developments for a full release? Your thought and feedback on this is very helpful. Thank you.

cc: @dev5, @dev4, @dev3, @dev2 @all

cintiadr · November 1, 2019, 9:55am

Is there any reason why this release is not being tested in UAT?

We have an environment only for acceptance tests for refapp releases, so if we won’t be using it anymore, I’d destroy it.

tendomart · November 1, 2019, 9:58am

@cintiadr

No please don’t i earlier asked but it looked like no one was using it,we still need it to optimize resources.

Have you considered these logs

cintiadr · November 1, 2019, 10:23am

Can you rephrase your questions?

I’m very confused what you mean by this.

Same.

tendomart · November 1, 2019, 10:25am

I have just redeployed the Refapp 2.9.0 after the broken builds and still throwing those errors.Any way to fix that ?

and this https://uat.openmrs.org/ is unavailable

cintiadr · November 1, 2019, 10:46am

Ok, let’s start from the beginning. Sorry, I got confused with the fact that you are releasing platform, and UAT-refapp is of course to be used only by refapp releases, not platform. We do not have an UAT environment for platform.

If you are attempting to release platform 2.3.0-beta, why would you redeployed refapp 2.9.0 to UAT-refapp? That’s very confusing. So let’s just fix builds that should exist in the first place.

This is not a valid URL If you have questions about our environments, please refer to docs

tendomart · November 1, 2019, 12:06pm

Thanks , i thought there was some sort of UAT server for platform , that’s why i asked.

about the error log above , the latest was showing errors run by you , am thinking it’s either 2.9.0 latest running or SNAPSHOT-2.10.0

mksd · November 1, 2019, 10:09pm

@ruhanga as discussed within @MekomSolutions, I think we’re the only ones actively maintaining test/QA/UAT servers running Core 2.3.x.

So far so good, @wyclif, thoughts?

ruhanga · November 4, 2019, 9:35am

Great @mksd. Thanks very much. I hope to have the full platform release by Tuesday(tomorrow) the 5th of November. Special thanks to every one that has contributed to this cause.

mozzy · November 4, 2019, 9:58am

But is there any reason we (the community) have no single current UAT/QA test enviroment for the platform??. we seem to have alot of servers for the reff app and no single one for the platform .

cc @cintiadr @dkayiwa

cintiadr · November 4, 2019, 10:17am

The reason is pretty simple. It wasn’t needed so far.

There are no automated tests in platform that require an external qa-platform environment; so no reason to create it. The qa-refapp should be only used by automated builds in refapp, which was already there.

The UAT-platform wasn’t created because no one cared enough to create the environment.

If there’s an actual demand and I get some help, it’s not hard. But then I need guarantees that it’s going to be updated regularly after releases (which is currently not happening with the mdsbuilder, our only platform environment - which is not a build one).

mozzy · November 4, 2019, 10:36am

i was going to mention about mdsBuilder but you know that is strictly restricted to very few people and release managers , we shouldnt even talk about that

I think the demand is there , every thing we do depends on the platform , new fixes are added every now and then . I think that is demand enough

which help is needed exactly ?? i dont think we can fail to offer the help if specified.

Otherwise Good job your doing @cintiadr

cintiadr · November 4, 2019, 10:58am

We already have a CI build that updates docker image openmrs-distro-platform in docker hub. It would need someone to add deployments to deploy tag ‘uat’ tag to dockerhub; exactly like it’s done to uat-refapp.

From there, a new docker service needs to be created in our docker-ansible repo, and that needs to have all the data needed on start up. UAT-platform will be recreated every couple of days.

Only the Infra team can then deploy this application to a server, including monitoring.

The last mile is updating wiki docs, creating a build to reset data in the server, change deployment to update the server, and so on.

mozzy · November 4, 2019, 11:16am

Ill try do all that i can … Can we create a ticket for this to track down the work ?

cintiadr · November 4, 2019, 11:18am

For the build, it’s ok to change directly in CI (I can review later).

For the code changes, all should require pull requests.

mozzy · November 4, 2019, 11:19am

Can you create a ticket for it ?

mksd · November 4, 2019, 11:50am

We run a custom Ref App 2.10 on Core 2.3.x. It’s still early but it looks like it’s ok. Keep in mind that we are in QA stages, entering UAT.

Just to say that we might consider having Ref App 2.10 run on Core 2.3.x. This should be the subject of another thread though.

mozzy · November 4, 2019, 11:58am

That sounds intresting.

mogoodrich · November 20, 2019, 9:14pm

Hello all… we’ve been testing against the 2.3.0-SNAPSHOT and have run into some interesting failing unit tests in one of our builds that will need some debugging. I’m guessing it has been caused by the change to the Person hibernate mapping.

This test, which was previously passing, fails when run against 2.3.0-SNAPSHOT:

github.com

PIH/openmrs-module-pihcore/blob/master/api/src/test/java/org/openmrs/module/pihcore/search/PihPatientSearchAlgorithmTest.java#L82


      
          
          
    assertThat(results.size(), is(1));
              assertThat(results.get(0).getPatient().getPersonName().getGivenName(), is("Jarus"));
              assertThat(results.get(0).getPatient().getPersonName().getFamilyName(), is("Rapondi"));
          
          
}
          
          
@Test
          public void shouldExcludeVoidedPatients() {
          
          
    Patient patientToVoid = patientService.getPatient(13);
              patientService.voidPatient(patientToVoid, "test");
              Context.flushSession();
          
          
    Patient patient = new Patient();
          
          
    PersonName name = new PersonName();
              patient.addName(name);
              name.setGivenName("Jarusz");
              name.setFamilyName("Rapondee");

In this case, the “voided” patient is now returned in the query.

Note that we void the patient in the first part of the test, so this may only be a problem that manifests itself during testing, but needs further exploring.

Looking deeper, the following test in core still passes…

github.com

openmrs/openmrs-core/blob/master/api/src/test/java/org/openmrs/api/PatientServiceTest.java#L1573


      
          	/**
          	 * @see PatientService#voidPatient(Patient,String)
          	 */
          	@Test
          	public void voidPatient_shouldVoidGivenPatientWithGivenReason() throws Exception {
          		Patient patient = Context.getPatientService().getPatient(2);
          		Patient voidedPatient = Context.getPatientService().voidPatient(patient, "Void for testing");
          		
          		assertTrue(voidedPatient.getVoided());
          		assertEquals("Void for testing", voidedPatient.getVoidReason());
          		assertFalse(Context.getPatientService().getAllPatients(false).contains(patient));
          	}
          	
          	/**
          	 * @see PatientService#voidPatient(Patient,String)
          	 */
          	@Test
          	public void voidPatient_shouldVoidAllPatientIdentifiersAssociatedWithGivenPatient() throws Exception {
          		Patient patient = Context.getPatientService().getPatient(2);
          		Patient voidedPatient = Context.getPatientService().voidPatient(patient, "Void for testing");
          		for (PatientIdentifier patientIdentifier : voidedPatient.getIdentifiers()) {

… but when I put a breakpoint at 1756 in debugger I’m seeing the following strange configuration which I suspect is causing the problem when running a search:

2019-11-20_16-06 2019-11-20_16-06_1

But when I run this test in Core 2.2.x I see the following (which is what I would expect):

2019-11-20_16-11

fyi @mksd @wyclif @dkayiwa @mseaton

Take care, Mark

mogoodrich · November 20, 2019, 9:32pm

Okay, so I see that we added a bunch of fields to the Patient object in order to apply the mappings as annotations instead of in a separate mapping file, and these fields are identical to fields already on BaseOpenmrsData which I assume is what is causing the problem:

github.com

openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/Patient.java#L59


	private Integer patientId;
	
	@Column(name = "allergy_status", length = 50)
	private String allergyStatus = Allergies.UNKNOWN;
	
	@OneToMany(mappedBy = "patient", cascade = CascadeType.ALL, orphanRemoval = true)
	@SortNatural
	@ContainedIn
	private Set<PatientIdentifier> identifiers;
	
	@ManyToOne
	@JoinColumn(name = "creator", updatable = false)
	@Access(AccessType.PROPERTY)
	private User creator;
	
	@Column(name = "date_created", nullable = false, updatable = false, length = 19)
	@Access(AccessType.PROPERTY)
	private Date dateCreated;
	
	@Column(name = "voided", nullable = false)
	@Access(AccessType.PROPERTY)