All Activity

jkeiperjkeiper (deleted user)

updated 2 fields of FORM-105

15:09
jkeiperjkeiper (deleted user)

closed FORM-107

15:07
jkeiperjkeiper (deleted user)

commented on FORM-107

15:06

committed in rev:15350

jkeiperjkeiper (deleted user)

changed the status to Code Review (Post-Commit) of FORM-107

15:06

Apparently dwrLoadingMessage (Javascript variable) was no longer defined, so I copied several lines from core's headerFull.jsp into taskpaneHeader.jsp in FormEntry. That worked.

jkeiperjkeiper (deleted user)

started progress on FORM-107

15:03
jkeiperjkeiper (deleted user)

closed FORM-108

15:02
jkeiperjkeiper (deleted user)

changed the status to Code Review (Post-Commit) of FORM-108

15:01

committed in rev:15350

jkeiperjkeiper (deleted user)

changed the status to Ready for Work of FORM-107

14:56
jkeiperjkeiper (deleted user)

started progress on FORM-108

14:56
jkeiperjkeiper (deleted user)

updated 6 fields of FORM-108

14:55
jkeiperjkeiper (deleted user)

changed the Summary to 'FormSchemaBuilder not working properly in FormEntry on OpenMRS 1.7' on FORM-108

14:54
jkeiperjkeiper (deleted user)

commented on FORM-108

14:53

The title of this ticket is a little misleading; the built-in schema builder for forms works fine but the XSN publisher uses a class called FormSchemaBuilder that generates a string from the form's schema, and that builder was not sorting the answers the same way FormTemplateBuilder was. Hence, InfoPath could not accept an XML file that did not match the schema.

jkeiperjkeiper (deleted user)

updated 6 fields of FORM-107

14:48
Wyclif Luyima

commented on TRUNK-1723

13:59

Nice, when editing details of a code review or during creation, you have the option of linking a ticket to it, so that when one clicks the 'reviews' tab of the ticket , they can see the associated code reviews.

Michael Downey

changed the Link to 'This issue duplicates ITSM-563' on TRUNK-1728

13:52
Mike Seaton

committed 15348 to Modules

13:27
htmlformentry: Remove override
Misha Koshelev

committed 15346 to Modules

13:14
spreadsheetimport module: initial import for GUI redesign/mockup, basicmodule+ (folders)
Misha Koshelev

deleted an attachment from TRUNK-1728

13:10
Misha Koshelev

attached one file to TRUNK-1728

13:03
Misha Koshelev

created TRUNK-1728

13:01
Misha Koshelev

attached one file to TRUNK-1708

12:45

Sorry last jar. Thank you.

Misha

Misha Koshelev

attached 3 files to TRUNK-1708

12:44

Hi. This is what I believe the patch should be.

Unfortunately your 1.0 version did not quite work, as for some reason you deleted the file metadata/moduleApplicationCtext.xml completely

However, I am more than happy to give you credit for the patch, as I like your:

  • comments
  • idea to use the patient that actually already exists in default OpenMRS database
    quite a bit.

I have made the libs for version 1.6.0 as I believe Darius advised me to use 1.6.0 for my spreadsheetimport module on IRC chat.

http://wiki.openmrs.org/display/IRC/2010-08-20

20:23:08 <misha680> ok here's a more important question... BasicModule uses OpenMRS 1.5 API. It seems to differ quite a bit from trunk. Which API version should new modules use (i.e., which would help most existing users)? Thank you
20:23:42 <chopin> foo
20:23:56 <nribeka> trunk
20:24:02 <downeym> bar
20:24:04 <nribeka> i cast my vote on trunk
20:24:23 <djazayeri> I would say start with 1.6
20:24:41 <djazayeri> if you run into a bug and need to switch to 1.7 or trunk, do that, but not until then.
20:24:47 <misha680> thank you djazayeri. just checking.
20:24:55 <downeym> djazayeri++
20:25:08 <djazayeri> 1.6 is probably your sweet spot for getting existing users, and using relatively recent code

Michael Downey seems to have supported him in this case.

Thank you
Misha

p.s. I am also attaching the relevant added jars as I don't know how to put them into the patch.

Mike Seaton

created TRUNK-1727

12:21
Misha Koshelev

commented on TRUNK-1708, TRUNK-1723

11:34