Request for a release of Attachments 2.3.0 and HFE 3.11.0

Tags: #<Tag:0x00007f0f198b36a0> #<Tag:0x00007f0f198b3510> #<Tag:0x00007f0f198b33a8>

We are planning to release soon a new version of a distro and wanted to leverage the bug fixes in the Attachment module 2.3.0-SNAPSHOT which currently depends on HFE 3.11.0-SNAPSHOT. Its on this note that am requesting for a new release of these two modules. cc. @mksd @mogoodrich @dkayiwa @ssmusoke

1 Like

Is this of help? https://wiki.openmrs.org/display/docs/Releasing+a+Module+from+Bamboo

1 Like

I’m ok with both being released.

@mogoodrich?

1 Like

I should be fine with HFE 3.11.0 being released… I will review and release, is there a timeframe needed?

Thanks, Mark

1 Like

@mogoodrich as we plan to release HFE 3.11.0 I have noticed something aberrant happening when i am creating a new form…AdminDao error is thrown when you save the form though the file is actually saved when you go back to manage Forms. Have you had a chance to look at it? cc. @mksd

@reagan can you describe the steps to reproduce the issue?

Steps to reproduce:

  1. Log in to qa-server

  2. Go to System Administration -> Advanced ->Advanced Administration-> Manage HTML Forms

  3. Click New HTML FORM -> Fill in the meta data

  4. Save Form even without making any changes…and it will throw error.

Same steps on demo work flawlessly

Between demo and QA, can you narrow this down to either Core being upgraded or HFE being upgraded?

The error seems to be coming from HFE though am failing to pinpoint the exact line causing it…The stack trace led me upto this new line of code added by @ibacher though I cant seem to see the transition from HFE to core where this method is called that finally leads to our error…

@reagan The error you reported is being raised here. The only line that commit you referenced touched is after that point (and you’d be getting a different error… all that line does is try to parse the purported HTMLForm document into a valid XML document).

I also note the headline error message is:

org.openmrs.api.APIException: Couldn't find a class in the hibernate configuration named: org.openmrs.Form$HibernateProxy$ddrvQal5
1 Like

I have tried to research the source of this error without much avail though have noted something that I think @dkayiwa might be in better position to weigh in about since he made a couple of changes as pertains to the method causing the error during the HIBERNATE library updates.

  1. When is setApplicationContext method called in the life cycle of this bean in relation to the time when metadata is used in our method

Otherwise the oldway seems to have loaded the configuration right inside the method as seen here (*Not sure it makes a diff though) cc @mksd @ibacher

@reagan which openmrs platform version are you running?

I am not running a local instance…Been using the qa-server generated stack-trace to follow the different method calls with the assumption that the qa server is running the latest changes…

Committed at https://github.com/openmrs/openmrs-core/commit/f4f7f1ca460e0b6537400b8dd346226127fb445d

Thanks @dkayiwa for the fix…Can we go ahead with the release? @mksd and @mogoodrich

@reagan yes for me :+1:

1 Like

@dkayiwa I am assuming that this also calls for back porting and a point release of core in the 2.3.x series for us who are on it

1 Like

@ssmusoke what i fixed was a problem only on the current master (2.4.0-SNAPSHOT) branch of the platform.

1 Like

@ssmusoke @reagan in the meantime we have found an issue with HFE that @samuel34 is investigating. So it’d be great if we could hold off a bit longer.

1 Like

@mksd yes we can probably up to early next week

1 Like