| 00:17:25 | *** mandric has quit IRC |
| 00:32:17 | *** mandric has joined #openmrs |
| 01:00:00 | *** goutham has joined #openmrs |
| 01:06:22 | *** goutham has quit IRC |
| 01:09:37 | *** wyclif has joined #openmrs |
| 01:10:17 | *** goutham has joined #openmrs |
| 01:25:41 | *** nribeka has quit IRC |
| 02:07:36 | *** goutham has quit IRC |
| 02:38:02 | *** guduji has joined #openmrs |
| 03:05:56 | *** guduji has quit IRC |
| 03:21:09 | *** mccallumg has joined #openmrs |
| 03:21:09 | *** ChanServ sets mode: +v mccallumg |
| 03:52:29 | *** pratyush has joined #openmrs |
| 04:10:30 | *** surangak has joined #openmrs |
| 04:11:15 | <surangak> mccallumg, hi |
| 04:11:25 | <surangak> mccallumg, very sorry about t being late today |
| 04:11:40 | <surangak> mccallumg, things are rather hectic over here.. :P |
| 04:12:48 | <mccallumg> no problem |
| 04:13:12 | <mccallumg> surangak: how's it goin? |
| 04:14:23 | <surangak> mccallumg, burke had answerd my mail |
| 04:14:31 | <surangak> mccallumg, still have to read it in detail |
| 04:14:54 | <surangak> mccallumg, today new set of intern have arrived at office, im supposed to oversee em |
| 04:15:02 | <surangak> mccallumg, was running about all day :D |
| 04:15:16 | <mccallumg> surangak: ok. i haven't seen that response. was I cc'd on it? |
| 04:15:45 | <surangak> mccallumg, oh i see, he has cc'd it to the dev list... |
| 04:16:02 | <mccallumg> surangak: when you build your branch with maven, do you run the tests? |
| 04:16:06 | <surangak> mccallumg, let me forward that to you... |
| 04:16:14 | <surangak> mccallumg, yes, |
| 04:16:25 | <mccallumg> surangak: no,no. i'll look atthe list |
| 04:16:25 | <surangak> mccallumg, so far there are no test faliures |
| 04:16:38 | <surangak> mccallumg, but five test errors... |
| 04:16:43 | <surangak> yesterday i fixed one.. |
| 04:17:04 | <surangak> mccallumg, so now only 4 test faliures |
| 04:17:15 | <mccallumg> mccallumg: i'm getting a failure but it is probably my setup |
| 04:18:00 | <mccallumg> surangak: i'll keep looking at it. do you need to go take care of your interns? |
| 04:18:03 | <surangak> mccallumg, what is the error msg ? |
| 04:18:14 | <surangak> mccallumg, they can survive for an hour without me |
| 04:18:30 | <surangak> mccallumg, unless they approach the Architect by mistake :D |
| 04:18:41 | <mccallumg> Failed tests: |
| 04:18:41 | <mccallumg> handle_shouldNotUnvoidTheOrdersAndEncountersThatNeverGotVoidedWithThePatient(org.openmrs.api.handler.PatientDataUnvoidHandlerTest) |
| 04:19:08 | <surangak> mccallumg, aha, yes, you're getting that too... |
| 04:19:17 | <surangak> mccallumg, let me explain that... |
| 04:19:47 | <surangak> mccallumg, i seem to be getting that even if i check out the latest tunk and run it without a single chance |
| 04:20:09 | <surangak> mccallumg, according to our integration test, all the tests are working |
| 04:20:36 | <surangak> mccallumg, i talked to ben about this,, but he was not getting it... we assumed that i was getting it because of some form of localization problem |
| 04:20:44 | <mccallumg> surangak: interesting. so it is doing it on the trunk too |
| 04:20:54 | <surangak> mccallumg, for now im ignoring that test with a @ignore |
| 04:20:58 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (order-entry): Follow up to API support for Discontinuing orders and fixing unit tests in OrderServiceTest - TRUNK-2367 <http://feedproxy.google.com/~r/OMRStrunk/~3/ws0ey-uvlVo/OpenMRS> |
| 04:21:11 | <surangak> mccallumg, since it does not affect the changes i am making to the branch |
| 04:21:32 | <surangak> mccallumg, but if you are also getting it, i better look into it some more |
| 04:21:50 | <surangak> for now, as a quick fix, how about adding @ ignore.. |
| 04:21:57 | <surangak> mccallumg, i will follow this up... |
| 04:22:38 | <surangak> mccallumg, or alternatively, do this.. |
| 04:22:55 | <surangak> mccallumg, mvn clean install -Dmaven.test.skip=true |
| 04:23:07 | <surangak> mccallumg, to ignore tests |
| 04:23:17 | <mccallumg> mccallumg: yes. that ignores all tests |
| 04:28:00 | <surangak> mccallumg, ah, burke has responded to both e mails i see |
| 04:36:31 | <mccallumg> surangak: just sent an email to you with maven failure message (I understand if now isn't the best time. :) |
| 04:36:43 | <surangak> mccallumg, hi, i just got it |
| 04:37:03 | <surangak> mccallumg, mm.. can you tell me the exact command you are running... |
| 04:37:13 | <surangak> mccallumg, from the root ? |
| 04:38:53 | <mccallumg> surangak: I'm using m2e. Right click on openmrs maven module. Run as > Maven build ... (parameters - clean install) |
| 04:40:31 | <mccallumg> surangak: pardon me. not parameters. Goals = clean install |
| 04:40:53 | <surangak> mccallumg, mmm... give me a minute to check that... u r a Mac user right ? |
| 04:41:29 | <mccallumg> surangak: yes. I'm doing this on my mac |
| 04:43:33 | <mccallumg> surangak: no hurry. we can talk more on the weekend. |
| 04:44:59 | <surangak> mccallumg, hi, i was trying to figure out what the problem was.. |
| 04:45:14 | <surangak> mccallumg, i think it should be a set up problem |
| 04:46:15 | <mccallumg> surangak: yes. I'm sure. It seems more people are skipping the tests during maven build (from looking at this thread: http://openmrs-mailing-list-archives.1560443.n2.nabble.com/Maven-build-of-openmrs-api-fails-td6220118.html) |
| 04:46:21 | <OpenMRSBot> <http://ln-s.net/8xf_> (at openmrs-mailing-list-archives.1560443.n2.nabble.com) |
| 04:46:37 | <surangak> mccallumg, all tests take 5-6 minutes to run |
| 04:46:46 | <surangak> mccallumg, so they usually run tests before committing |
| 04:46:51 | <mccallumg> surangak: right |
| 04:47:18 | <surangak> mccallumg, i was wondering, in eclipse,where you set the goal, is your maven config displayed properly ? |
| 04:48:08 | <surangak> mccallumg, something like D:\JavaIDEs\springsource-tool-suite-2.6.0.RELEASE-e3.6.2-win32-1\springsource\maven-2.2.1.RELEASE\conf\settings.xml |
| 04:48:47 | <mccallumg> surangak: it is the eclipse wizard so I don't actually see the maven command. should I? |
| 04:49:30 | <surangak> mccallumg, mm... are you using the bundled in maven in your ide, or have u installed exxternally ? |
| 04:49:48 | <mccallumg> surangak: just m2e in eclipse ... |
| 04:49:55 | *** gbastien has quit IRC |
| 04:50:13 | <surangak> mccallumg, go windows ->preferences - >maven -> installations |
| 04:50:34 | <surangak> mccallumg, you will need maven to run it, im afraid... |
| 04:50:44 | <mccallumg> surangak: I do have maven on the command line |
| 04:51:42 | <surangak> mccallumg, mm.... did u try running maven from the command line ? |
| 04:52:02 | <surangak> mccallumg, instead of going through ecplise... |
| 04:52:12 | <mccallumg> surangak: I'll try that ... tomorrow |
| 04:52:21 | <surangak> mccallumg, sorrry, still trying to figure out the problem, mine seems to run ok... |
| 04:52:38 | <surangak> mccallumg, no problem, ill try to figure out what is happenin... |
| 04:52:45 | <mccallumg> surangak: no worries. It is time for me to retire anyway. |
| 04:53:00 | <mccallumg> surangak: I'll be in touch over the weekend. I'm sure |
| 04:55:45 | *** pratyush has left #openmrs |
| 04:56:52 | <mccallumg> surangak: bye |
| 04:57:25 | <surangak> mccallumg, bye glen, sorry about that.. ill look into the two issues today... |
| 04:57:50 | <mccallumg> surangak: there's nothing for you to look into. I'm sure it is setup on my end. |
| 05:05:57 | *** mccallumg has quit IRC |
| 05:14:06 | *** dkayiwa has joined #openmrs |
| 06:10:46 | *** bwolfe has joined #openmrs |
| 06:10:46 | *** ChanServ sets mode: +o bwolfe |
| 06:16:00 | *** mathiaslin has joined #openmrs |
| 06:57:19 | *** pascal` has joined #openmrs |
| 07:16:22 | *** bwolfe has quit IRC |
| 07:16:41 | *** upul` has joined #openmrs |
| 07:16:41 | *** ChanServ sets mode: +v upul` |
| 07:17:53 | *** bwolfe has joined #openmrs |
| 07:17:53 | *** ChanServ sets mode: +o bwolfe |
| 07:23:09 | *** bwolfe has quit IRC |
| 07:25:26 | *** bwolfe has joined #openmrs |
| 07:25:26 | *** ChanServ sets mode: +o bwolfe |
| 07:35:41 | *** bwolfe has quit IRC |
| 07:40:56 | *** bwolfe has joined #openmrs |
| 07:40:56 | *** ChanServ sets mode: +o bwolfe |
| 07:46:03 | *** bwolfe has quit IRC |
| 07:58:47 | *** bwolfe has joined #openmrs |
| 07:58:47 | *** ChanServ sets mode: +o bwolfe |
| 08:01:47 | *** gauravpaliwal has joined #openmrs |
| 08:01:47 | *** ChanServ sets mode: +v gauravpaliwal |
| 08:02:23 | <gauravpaliwal> what is the alternative to this if I need data back from the portlet to the controller <property name="successView"><value>redirect:newjsp.portlet</value></property> |
| 08:02:25 | <gauravpaliwal> ? |
| 08:02:38 | <gauravpaliwal> bwolfe: Hi |
| 08:02:51 | <gauravpaliwal> what is the alternative to this if I need data back from the portlet to the controller <property name="successView"><value>redirect:newjsp.portlet</value></property> ? |
| 08:02:53 | <bwolfe> hey |
| 08:03:41 | <gauravpaliwal> bwolfe : what is the alternative to this if I need data back from the portlet to the controller <property name="successView"><value>redirect:newjsp.portlet</value></property> ? |
| 08:03:44 | <bwolfe> you mean from the controller to the portlet again? |
| 08:04:08 | <gauravpaliwal> from portlet to the controller |
| 08:04:45 | <bwolfe> successview is for after the controller receives the submission |
| 08:05:00 | <bwolfe> your portlet needs to submit to a different url |
| 08:05:11 | <gauravpaliwal> okey cool ! |
| 08:05:13 | <bwolfe> just create a new controller and set to form action url to be that controller |
| 08:06:09 | <gauravpaliwal> I have done that :) and it works :) , |
| 08:10:36 | <bwolfe> portlets are meant to be readonly |
| 08:10:38 | <bwolfe> displayonly |
| 08:12:26 | <gauravpaliwal> okeys.. |
| 08:33:32 | <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Forum: Customizing OpenMRS <http://forum.openmrs.org/viewtopic.php?f=22&t=788#p2986> || New Changeset: OpenMRS (trunk): IN PROGRESS - issue TRUNK-2428: ConcurrentModificationException in ConceptNameSaveHandler ... <http://feedproxy.google.com/~r/OMRStrunk/~3/W6FyqXTv-UY/OpenMRS> || Shazin Sadakath: First Class <http://shazsterblog.blogspot.com/2011/07/first-class.html> |
| 08:58:34 | <surangak> so as you all can see by the latest update by openmrs bot, Shazin just won himself a first class.... |
| 08:58:49 | <surangak> and we're all very pleased about it over here in Sri Lanka... |
| 09:19:28 | *** gauravpaliwal has quit IRC |
| 09:47:43 | *** surangak has quit IRC |
| 10:02:36 | <bwolfe> congrats to shazin! |
| 10:02:49 | <bwolfe> where is he btw.. ? I haven't seen him for a long while... |
| 10:03:24 | <pascal`> shazin++ |
| 10:03:31 | *** ChanServ sets mode: +v pascal` |
| 10:04:34 | <pascal`> bwolfe, tried out the g+ mobile app? |
| 10:04:42 | <pascal`> no iphone release "yet". |
| 10:04:53 | <bwolfe> I don't have an invite for it |
| 10:05:13 | <bwolfe> and I'm not really into the social scene anyway. I feel like if I swear off facebook I need to sweat off g+ ;-) |
| 10:06:33 | <pascal`> bwolfe, sure, but you have to at least try it out |
| 10:15:51 | *** mandric_ has joined #openmrs |
| 10:15:52 | *** mandric has quit IRC |
| 10:15:54 | *** mandric_ is now known as mandric |
| 10:29:28 | *** james_regen has joined #openmrs |
| 10:29:37 | *** ChanServ sets mode: +v james_regen |
| 10:31:09 | *** surangak has joined #openmrs |
| 10:31:48 | <surangak> bwolfe, i see i just got unassigned from an old introductory ticket... |
| 10:32:55 | <bwolfe> surangak, yeah, cleaning things up |
| 10:33:06 | <bwolfe> if you still are doing it, feel free to reclaim it. :-) |
| 10:33:13 | <surangak> bwolfe, there were a few more tickets like that... |
| 10:33:22 | <bwolfe> that you own? |
| 10:33:29 | <bwolfe> can you unassign yourself if you're not working on them? |
| 10:33:30 | <surangak> bwolfe, but i guess you're right.. someone new might turn up and do them now |
| 10:33:40 | <surangak> bwolfe, let me go through them |
| 10:34:04 | <surangak> bwolfe, later on, after gsoc, ill be too old for introductory tickets :P |
| 10:34:37 | <bwolfe> very true |
| 10:35:49 | <surangak> bwolfe, ill go through the tickets today - tomorrow morning and do that... :-) |
| 10:36:43 | <bwolfe> ok, thanks! |
| 11:06:07 | <surangak> bwolfe, by the way, shazin just graduated |
| 11:06:29 | <dkayiwa> who is shazin? |
| 11:06:35 | <bwolfe> I know, did you not see my comment after your previous one about it? :-) |
| 11:15:21 | *** rafa has joined #openmrs |
| 11:15:21 | *** ChanServ sets mode: +v rafa |
| 11:15:24 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (webapp-testing): Added changes from APPTEST-48, APPTEST-34, APPTEST-38, APPTEST-36, APPTEST-3, APPTEST-39 <http://feedproxy.google.com/~r/OMRStrunk/~3/ib6KTlShIX8/OpenMRS> || New Changeset: OpenMRS (order-entry): Adding a UI widget for choosing an Orderable - TRUNK-2383 <http://feedproxy.google.com/~r/OMRStrunk/~3/TX_kN32HJEQ/OpenMRS> || OpenMRS Forum: Re: Customizing OpenMRS <http://forum.openmrs.org/viewtopic.php?f=22&t=788#p2987> |
| 11:15:27 | *** Echidna has quit IRC |
| 11:15:53 | <surangak> dkayiwa, he is like. the guy who got me intrested in OpenMRS |
| 11:16:04 | <dkayiwa> oh i see!!! :) |
| 11:16:08 | <surangak> dkayiwa, i have a big case of hero worship on him :) |
| 11:16:17 | <dkayiwa> hahahah :D |
| 11:18:05 | *** upul` has left #openmrs |
| 11:24:48 | *** Echidna has joined #openmrs |
| 11:24:48 | *** ChanServ sets mode: +v Echidna |
| 11:50:08 | *** dkayiwa has quit IRC |
| 11:54:07 | *** dkayiwa has joined #openmrs |
| 12:05:02 | *** bryq has joined #openmrs |
| 12:05:02 | *** ChanServ sets mode: +v bryq |
| 12:05:32 | *** bwolfe has quit IRC |
| 12:08:07 | *** bwolfe has joined #openmrs |
| 12:08:07 | *** ChanServ sets mode: +o bwolfe |
| 12:08:34 | *** bryq has quit IRC |
| 12:17:49 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (order-entry): Added a minor change to getOrders dao method to exclude voided orders TRUNK-2365 <http://feedproxy.google.com/~r/OMRStrunk/~3/q7uoUgQJ8yI/OpenMRS> |
| 12:31:43 | *** downeym has joined #openmrs |
| 12:31:43 | *** ChanServ sets mode: +o downeym |
| 12:31:43 | *** OpenMRSBot sets mode: +o downeym |
| 12:32:00 | *** wyclif has quit IRC |
| 12:38:42 | *** bwolfe has quit IRC |
| 12:41:50 | <rafa> dkayiwa: Have you ever used ValidateUtil.validate() explicitly before saving? |
| 12:41:59 | <dkayiwa> yes |
| 12:44:24 | *** r4friedman has joined #openmrs |
| 12:44:49 | *** r4friedman is now known as r-friedman |
| 12:45:04 | <r-friedman> djazayeri: are you really there? |
| 12:45:26 | <rafa> dkayiwa: My problem is that when I call it, it doesn't validate the given object. |
| 12:45:44 | <rafa> dkayiwa: Do I have to setup something before calling validate? |
| 12:46:22 | <rafa> dkayiwa: I'm stepping through with a debugger and it actually does not find any Validators. |
| 12:48:28 | <dkayiwa> rafa: i remember you need to add your validator to the ValidateUtil in some .xml config file |
| 12:48:57 | <r-friedman> downeym: mike, are you actually there? |
| 12:48:58 | <rafa> dkayiwa: I want to use Concept validator which should be there already. |
| 12:50:49 | <dkayiwa> let me cross check |
| 12:54:11 | <dkayiwa> are you using trunk? |
| 12:54:59 | <rafa> dkayiwa: no, 1.7 branch |
| 12:55:53 | <dkayiwa> do you have this: <bean class="org.openmrs.validator.ValidateUtil"> |
| 12:56:07 | <dkayiwa> in applicationContext-service.xml |
| 12:56:09 | *** gauravpaliwal1 has joined #openmrs |
| 12:57:19 | <dkayiwa> i think it was removed from trunk. but could be still existing in 1.7 |
| 12:57:57 | <rafa> dkayiwa: it's not there |
| 12:58:23 | <rafa> there're specific bean validators declared though |
| 12:58:31 | <downeym> r-friedman: yep. |
| 12:58:48 | <r-friedman> hey mike, did paul pick up the pkg at the front desk? |
| 12:59:03 | <downeym> r-friedman: I wasn't aware I had one waiting for me :) |
| 12:59:07 | <downeym> oh, paul |
| 12:59:10 | <downeym> no.... |
| 12:59:19 | <downeym> do you know when it was received? |
| 12:59:26 | <r-friedman> it was for everyone, why don't you follow up on it -- yesterday afternoon |
| 12:59:40 | <dkayiwa> rafa: i think the validation strategy which uses the ValidateUtil was changed in newer versions |
| 12:59:51 | <r-friedman> 2:44pm by Moore |
| 13:00:06 | <downeym> r-friedman: i'll call her |
| 13:00:41 | <rafa> dkayiwa: Okay, thanks. I'll continue to play with a debugger to see what happens. |
| 13:00:47 | <dkayiwa> ok |
| 13:02:40 | <dkayiwa> rafa: when you call ValidateUtil.validate, does ValidateUtil.getValidators get called? |
| 13:02:54 | <rafa> yes |
| 13:03:21 | <dkayiwa> rafa: and does it find any validator? |
| 13:03:28 | <rafa> no |
| 13:03:43 | <rafa> I'm stepping through org.openmrs.util.HandlerUtil.getHandlersForType(Class<H>, Class<T>) right now |
| 13:03:56 | <dkayiwa> which validator did you want to be found? |
| 13:04:12 | <rafa> ConceptValidator |
| 13:05:26 | <rafa> It's not returned by Context.getRegisteredComponents(handlerType) |
| 13:06:27 | <dkayiwa> and which object do you pass in ValidateUtil.validate? |
| 13:06:35 | <rafa> dkayiwa: Okay, I think I see where's the problem. Validators need to be specified explicitly in applicationContext-service.xml |
| 13:06:46 | <rafa> ConceptValidator is not there for unknown reason |
| 13:06:59 | <dkayiwa> ok |
| 13:07:24 | <rafa> dkayiwa: Thanks for hints :) |
| 13:07:32 | <dkayiwa> not much |
| 13:13:14 | *** guduji has joined #openmrs |
| 13:14:47 | <guduji> djazayeri: i have a question |
| 13:16:04 | *** bwolfe has joined #openmrs |
| 13:16:04 | *** ChanServ sets mode: +o bwolfe |
| 13:17:03 | <guduji> bwolfe: hi :) |
| 13:17:33 | <guduji> i m still stuck with that problem on selenium testing |
| 13:17:52 | <guduji> did you get my url of pastebin? |
| 13:19:05 | <bwolfe> hi ankur |
| 13:19:08 | <guduji> hi |
| 13:19:16 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (obs-codes-expanded): Crude fix to ObsValidator - redo this later <http://feedproxy.google.com/~r/OMRStrunk/~3/mMv1EgYNeOc/OpenMRS> |
| 13:19:37 | <bwolfe> paste it here? |
| 13:19:55 | <guduji> oh ok |
| 13:20:09 | <guduji> u want the release-test script right? |
| 13:20:53 | <guduji> #!/bin/bash |
| 13:20:53 | <guduji> function usage() { |
| 13:20:53 | <guduji> cat <<HELP |
| 13:20:53 | <guduji> usage: $0 [OPTION] |
| 13:20:53 | <guduji> Following are the options: |
| 13:20:53 | <guduji> -i Execute the test in integration mode (default mode is smoke) |
| 13:20:55 | <guduji> -t <test> 'test' is the name of the testcase to be run |
| 13:20:57 | <guduji> -v To enable verbose logging |
| 13:20:59 | <guduji> -b Runs test in virtual buffer |
| 13:21:01 | <guduji> -u mysql username to use (defaults to "openmrs") |
| 13:21:03 | <guduji> -p mysql password to use (defaults to "test") |
| 13:21:05 | <guduji> -o OPENMRS username to use (if executing a single test) |
| 13:21:07 | <guduji> -w OPENMRS password to use (if executing a single test) |
| 13:21:11 | <guduji> -h Prints usage |
| 13:21:13 | <guduji> HELP |
| 13:21:15 | <guduji> } |
| 13:21:17 | <guduji> export MAVEN_OPTS="-Xmx1024m -Xms256m -XX:MaxPermSize=256m" |
| 13:21:19 | <guduji> dir=`dirname $0` |
| 13:21:21 | <guduji> cd $dir |
| 13:21:23 | <guduji> error=1 |
| 13:21:25 | <guduji> success=0 |
| 13:21:27 | <guduji> verbose="-q" |
| 13:21:29 | <guduji> buffer=false |
| 13:21:31 | <guduji> testname="*" |
| 13:21:33 | <guduji> profile="smoke-test" |
| 13:21:35 | <guduji> mysqlusername="openmrs" |
| 13:21:37 | <guduji> mysqlpassword="test" |
| 13:21:41 | <guduji> omrsusername="admin" |
| 13:21:43 | <guduji> omrspassword="Admin123" |
| 13:21:45 | <guduji> while getopts t:ivbhu:p:o:w: options |
| 13:21:47 | <guduji> do |
| 13:21:49 | <guduji> case $options in |
| 13:21:49 | <dkayiwa> [:) |
| 13:21:51 | <guduji> t ) testname=$OPTARG;; |
| 13:21:53 | <guduji> i ) profile="integration-test";; |
| 13:21:55 | <guduji> v ) verbose="";; |
| 13:21:57 | <guduji> b ) buffer=true;; |
| 13:21:59 | <guduji> u ) mysqlusername=$OPTARG;; |
| 13:22:01 | <guduji> p ) mysqlpassword=$OPTARG;; |
| 13:22:03 | <guduji> o ) omrsusername=$OPTARG;; |
| 13:22:05 | <guduji> w ) omrspassword=$OPTARG;; |
| 13:22:07 | <guduji> h ) usage |
| 13:22:11 | <guduji> exit $success;; |
| 13:22:13 | <guduji> \? ) usage |
| 13:22:15 | <guduji> exit $error;; |
| 13:22:17 | <guduji> esac |
| 13:22:19 | <guduji> done |
| 13:22:21 | <guduji> mvn_command="mvn integration-test -DskipTests -P $profile -Dtest=$testname $verbose -Dmysql_username=$mysqlusername -Dmysql_password=$mysqlpassword -Dopenmrs_username=$omrsusername -Dopenmrs_password=$omrspassword" |
| 13:22:23 | <dkayiwa> d:) |
| 13:22:24 | <guduji> echo Running $mvn_command |
| 13:22:26 | <guduji> echo "Use -v option for verbose mode if you run into errors" |
| 13:22:28 | <guduji> runcommand=$mvn_command |
| 13:22:30 | <guduji> # now run the tests in a hidden browser window (requires app called "xvfb") if the -b option has been passed |
| 13:22:33 | <guduji> if [ $buffer = true ]; then |
| 13:22:35 | <guduji> # kill other open xvfb-run processes |
| 13:22:37 | <guduji> pkill -9 -f Xvfb |
| 13:22:41 | <guduji> runcommand="xvfb-run $mvn_command" |
| 13:22:43 | <guduji> fi |
| 13:22:45 | <guduji> $runcommand |
| 13:22:47 | <guduji> http://pastebin.com/sTUK6Txw |
| 13:22:49 | <guduji> url for pastebin |
| 13:23:58 | <dkayiwa> that was a long one :D |
| 13:24:53 | *** wyclif has joined #openmrs |
| 13:26:20 | <guduji> dkayiwa: you saying that to me? :) |
| 13:26:25 | <dkayiwa> yes |
| 13:26:28 | <dkayiwa> :) |
| 13:26:31 | <guduji> oops sorry |
| 13:28:49 | *** jkeiper has joined #openmrs |
| 13:32:45 | *** docpaul has joined #openmrs |
| 13:33:05 | <downeym> r-friedman: |
| 13:33:07 | *** ChanServ sets mode: +o docpaul |
| 13:33:14 | <docpaul> 1pin1pinballhi roger! |
| 13:33:18 | <guduji> bwolfe: ^^ |
| 13:33:35 | *** gauravpaliwal1 has left #openmrs |
| 13:33:38 | <dkayiwa> jkeiper: welcome to IRC :) |
| 13:33:39 | <docpaul> er, hi roger! |
| 13:33:42 | <bwolfe> docpaul, looks like you have a stuttering problem |
| 13:33:46 | <r-friedman> docpaul: hi paul |
| 13:33:53 | <r-friedman> downeym: ni mike |
| 13:33:59 | <docpaul> roger, you sent something to me? :) |
| 13:34:03 | <docpaul> or to us? |
| 13:34:14 | <r-friedman> to y'all care of you |
| 13:34:14 | <docpaul> it wouldnt have anything to do with games, would it? |
| 13:34:20 | <r-friedman> hehe |
| 13:34:25 | <r-friedman> trying to reduce productivity |
| 13:34:38 | <docpaul> was it an icade? |
| 13:34:44 | <r-friedman> yassah |
| 13:34:51 | <downeym> r-friedman++ |
| 13:35:00 | <docpaul> wow, that freaks me out |
| 13:35:01 | * downeym takes the rest of the day off |
| 13:35:14 | <docpaul> because i thought that came from zeshan and nareesa |
| 13:35:36 | <docpaul> thanks roger! |
| 13:35:38 | <r-friedman> if it came yesterday afternoon, it was from me |
| 13:35:41 | <r-friedman> my pleasure |
| 13:35:46 | <r-friedman> enjoy |
| 13:36:09 | <jkeiper> dkayiwa, thank you ... thank you ... *bow* |
| 13:36:09 | <r-friedman> want openmrs to be envy of regenstief e-health |
| 13:36:33 | <docpaul> well, an arcade machine is a step in that direction LD |
| 13:36:36 | <docpaul> er, :D |
| 13:37:29 | <docpaul> what made you think of that? :) |
| 13:37:45 | <docpaul> it's just so wierd that others around here were talking about it was well! |
| 13:37:50 | <bwolfe> ...and why didn't you send one to the Eldoret Regenstrief office ? |
| 13:37:56 | <downeym> r-friedman has the place bugged :D |
| 13:38:00 | <r-friedman> cause y'all are biggest nest of ipad users |
| 13:38:24 | <r-friedman> haha, have you tried to get through Kenyan customs? |
| 13:38:35 | <docpaul> uh, yes. :D |
| 13:38:51 | <downeym> good luck with that |
| 13:39:07 | <bwolfe> I walk through it just fine ;-) |
| 13:39:20 | <bwolfe> sending anything of value via post however... |
| 13:40:23 | <r-friedman> i'm always carrying stuff to my ghana compadres |
| 13:40:40 | <r-friedman> last trip I had 5 1T hard drives |
| 13:40:54 | <bwolfe> heh |
| 13:41:12 | <r-friedman> but having our purchasing people ship 1 PC to Kenya was a bitch |
| 13:41:15 | <bwolfe> I think the biggest thing walked through kenya was a $8000 2u server |
| 13:41:54 | <r-friedman> Emory SPH has a number of international short courses |
| 13:42:08 | <bwolfe> guduji, I don't know why thats hanging for you. do other tests hang? did you see I committed some of your tests to the branch today? (including that drug one, since you put it in the other patches) |
| 13:42:10 | <r-friedman> When folks leave, they inevitably are carrying large flat screen TVs |
| 13:42:24 | *** mandric has quit IRC |
| 13:42:41 | <guduji> oh i did |
| 13:42:48 | <guduji> yes the other tests also give the same problem :( |
| 13:43:05 | <guduji> its just that it opens two tabs.. and then hangs dont know why |
| 13:43:19 | <guduji> i have two more test done if this problem is solved :S |
| 13:44:00 | <bwolfe> try a clean build ? |
| 13:44:24 | <guduji> you mean mvn clean ok |
| 13:45:31 | <bwolfe> yes |
| 13:45:55 | <bwolfe> also make sure there aren't any mysql or jetty instances still running in the bg |
| 13:46:14 | <bwolfe> before the commit I made there was a problem with the failed tests leaving mysql in the bg |
| 13:47:51 | <guduji> oh for that do i have to make some change in my files? |
| 13:48:10 | <guduji> cuz i just kill those instances on my terminal |
| 13:48:30 | *** pascal` has quit IRC |
| 13:49:55 | *** gbastien has joined #openmrs |
| 13:53:32 | <bwolfe> guduji, with my latest commit they should go away |
| 13:53:38 | <bwolfe> killing them at terminal is about the same |
| 13:54:21 | *** gbastien has quit IRC |
| 13:56:53 | <guduji> oh ok |
| 13:57:10 | <guduji> but i m still facing the same problem after doing a clean build too :/ |
| 13:57:52 | <guduji> (why did i upgrade my ubuntu) |
| 13:57:55 | <bwolfe> strange |
| 13:58:02 | <bwolfe> ha |
| 13:58:16 | <bwolfe> it was workign before the upgrade? |
| 13:58:20 | <guduji> yep |
| 13:58:23 | <guduji> working perfectly fine |
| 14:02:17 | <guduji> bwolfe: does it also opens up two tabs on the same browser window for you as well? |
| 14:02:23 | *** pascal` has joined #openmrs |
| 14:04:12 | <bwolfe> yes, if I don't use -b |
| 14:04:16 | <bwolfe> two tabs is ok |
| 14:04:21 | <bwolfe> its the not closing part that is bad :-p |
| 14:04:37 | <bwolfe> you can install xvfb and try using it in the bg with the -b flag |
| 14:07:14 | *** gbastien has joined #openmrs |
| 14:20:54 | *** pascal` has quit IRC |
| 14:21:06 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (order-entry): API support for finding active orders for a patient - TRUNK-2365 <http://feedproxy.google.com/~r/OMRStrunk/~3/1GY867Flt5w/OpenMRS> |
| 14:26:30 | <guduji> oh ok i will look into it |
| 14:26:45 | *** mandric has joined #openmrs |
| 14:27:05 | *** surangak has quit IRC |
| 14:27:54 | *** mandric has quit IRC |
| 14:29:15 | *** mandric has joined #openmrs |
| 14:30:00 | *** mandric has joined #openmrs |
| 14:31:47 | <guduji> bwolfe: i tried with -b .. it still hangs in between.. as if waiting for something |
| 14:31:58 | <bwolfe> strange |
| 14:32:11 | *** downeym has quit IRC |
| 14:32:20 | *** mandric has joined #openmrs |
| 14:32:26 | <guduji> hm... i will try to reinstall my browser and see |
| 14:32:45 | <bwolfe> guduji, did you confirm that no mysql or jetty or chrome is hanging around? |
| 14:34:21 | <guduji> yes |
| 14:34:25 | <guduji> and there is one more strange thing |
| 14:34:43 | <guduji> no matter what test i run... it always start with story of managing concept drugs |
| 14:34:48 | <guduji> may be thats the reason |
| 14:35:03 | <guduji> but i just changed the story.java file |
| 14:35:21 | <bwolfe> changed story to do what? |
| 14:35:33 | <guduji> story.java with the chrome driver |
| 14:35:37 | <bwolfe> oh, I see |
| 14:35:40 | <guduji> as you suggested day before yesterday |
| 14:35:45 | <guduji> yep |
| 14:35:51 | <bwolfe> yes, def strange if its always starting with that one |
| 14:36:16 | <guduji> how about i check out the webapp branch again and the paste my new files there to see? |
| 14:36:30 | <bwolfe> I can't think of why it'd do that or any other possible solution than a "mvn clean" |
| 14:36:49 | <guduji> yeah i did mvn clean too.. but still the same |
| 14:37:03 | <bwolfe> guduji, are you sure its building correctly? Any compile errors in the release-test branch? |
| 14:38:23 | <guduji> yep building correctly |
| 14:38:39 | <guduji> i do mvn install -DskipTests=true |
| 14:39:20 | <rafa> djazayeri: let me know when you have some time |
| 14:39:56 | <djazayeri> rafa: 5 mins |
| 14:40:03 | <rafa> perfect |
| 14:42:34 | *** downeym has joined #openmrs |
| 14:42:34 | *** OpenMRSBot sets mode: +o downeym |
| 14:42:34 | *** ChanServ sets mode: +o downeym |
| 14:43:37 | <guduji> wyclif: for trunk 235, how do i retrieve the information from the my profile page to be used in the index page |
| 14:44:36 | <guduji> like after going to my profile i click on the check box.. then that data i need it in the openmrssearch.js file to write a function to assign it to the new variable in that file |
| 14:48:21 | <dkayiwa> hi djazayeri |
| 14:49:33 | <dkayiwa> djazayeri: when filling an order, Burke suggested a filler with format: identifier::authority |
| 14:50:24 | <dkayiwa> djazayeri: so my question is, does that lead to getUserId + "::" authority ? if so, what is the value for authority? |
| 14:52:16 | <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Modules: i2b2 Export 1.0.5 uploaded to OpenMRS Module Repository <https://dev.openmrs.org/modules/view.jsp?module=i2b2export&version=&1.0.5> |
| 14:53:04 | <djazayeri> dkayiwa: for a local user in the db, say the authority is LOCAL |
| 14:53:48 | <djazayeri> rafa: I'm ready |
| 14:54:23 | <rafa> djazayeri: ok, let's start |
| 14:54:42 | <rafa> so the current state is: |
| 14:54:47 | <rafa> If it is the first import |
| 14:54:47 | <rafa> Defaults to merge if incoming date changed > existing date changed (needs to be confirmed) |
| 14:54:47 | <rafa> Defaults to omit if incoming date changed <= existing date changed (is confirmed) |
| 14:54:47 | <rafa> Defaults to merge if we cannot determine the dates (needs to be confirmed) |
| 14:56:11 | <rafa> My main rule is that omit is safe so we don't need to confirm that, but merge is unsafe and we ask to confirm |
| 14:56:33 | <djazayeri> That sounds right |
| 14:56:42 | <rafa> Do you want to compare it with next imports? |
| 14:56:53 | <djazayeri> We really do need to find a way to show more properties on the confirmation page |
| 14:57:07 | <djazayeri> otherwise it's pretty tricky for the user to decide |
| 14:57:17 | <djazayeri> This is in the case where we've matched on UUID? |
| 14:57:26 | <rafa> yes |
| 14:57:27 | <djazayeri> Actually, back up a step |
| 14:57:39 | <djazayeri> This is for the situation that we're importing something with a UUID we already have |
| 14:57:46 | <rafa> correct |
| 14:57:48 | <djazayeri> and it's the first time metadata sharing has imported it? |
| 14:57:53 | <rafa> correct |
| 14:58:59 | <djazayeri> Yeah, I agree that if the uuid is the same, we should determine the behavior based on dateChanged. |
| 14:59:08 | <djazayeri> And we should require confirmation for overwriting |
| 14:59:22 | <djazayeri> (unless they chose the "prefer to overwrite" option at the very beginning. |
| 14:59:32 | <rafa> Yes |
| 14:59:41 | <rafa> They'll see everything green then |
| 15:00:29 | <rafa> But in that case should we always default to merge? |
| 15:00:32 | *** downeym sets mode: +v yanokwa |
| 15:00:36 | *** downeym sets mode: +v wyclif |
| 15:00:38 | *** downeym sets mode: +v r-friedman |
| 15:00:43 | *** downeym sets mode: +v dkayiwa |
| 15:00:46 | *** downeym sets mode: +v asgoyal_ |
| 15:00:49 | <rafa> Or leave omit for the one case? |
| 15:00:50 | *** downeym sets mode: +v jkeiper |
| 15:00:54 | *** downeym sets mode: +v mathiaslin |
| 15:01:04 | <downeym> man, you guys need to register with nickserv. :P |
| 15:01:07 | <djazayeri> leave omit for the case where dateModified is exactly equal. |
| 15:01:43 | <djazayeri> So, the meaning of that option is "I am importing a package from someone who I actually trust to do metadata management for me, and I'm not really managing this stuff myself" |
| 15:02:06 | <rafa> Ok |
| 15:02:25 | <djazayeri> I.e. it should support the use case where Mark is pushing out an update to all users of the MDR-TB module, or Andy is pushing out an update to people using the MVP dictionary. |
| 15:02:25 | <rafa> We should probably write that sentence :) |
| 15:02:33 | <djazayeri> I agree, copy it down. :-) |
| 15:02:54 | <djazayeri> so in that case we really do not want to ask for confirmation. |
| 15:03:05 | <rafa> Clear |
| 15:03:17 | <djazayeri> (but we omit in the case that dateChanged is exactly the same) |
| 15:03:39 | <rafa> Yes, to prevent unnecessary updates in the db |
| 15:04:17 | <djazayeri> exactly |
| 15:04:21 | <rafa> Okay let's consider next imports for the same uuids |
| 15:04:26 | <rafa> If it is not the first import |
| 15:04:26 | <rafa> Defaults to merge if last import date < existing date changed (is confirmed if previously was merge) |
| 15:04:26 | <rafa> Defaults to merge if incoming date changed > last import date changed (is confirmed if previously was merge) |
| 15:04:27 | <rafa> Defaults to omit if incoming date changed <= last import date changed (is confirmed) |
| 15:04:27 | <rafa> Defaults to merge if we cannot determine the dates (needs to be confirmed) |
| 15:06:37 | <djazayeri> Is this just for identical uuids? or also uuids that have been mapped? |
| 15:06:56 | <rafa> It's just for identical uuids |
| 15:07:02 | *** dkayiwa_ has joined #openmrs |
| 15:07:24 | <rafa> Things that have been mapped always get previously chosen action at the moment. |
| 15:07:56 | <rafa> We should probably change that. |
| 15:08:26 | <djazayeri> So, that sounds fine to me. |
| 15:08:42 | <djazayeri> I suspect Andy and Roger might say we should default to omit in case 1 and 4 |
| 15:08:54 | <djazayeri> but I think merge is fine for now |
| 15:09:00 | *** dkayiwa has quit IRC |
| 15:09:00 | *** dkayiwa_ is now known as dkayiwa |
| 15:09:38 | <rafa> So the first case is if you modify your data after import and try to import things again. |
| 15:10:05 | <rafa> You'll revert back to what was in the package. |
| 15:10:50 | <djazayeri> Actually in that case I'd like it to default to either merge OR omit, depending on what you chose in the initial "prefer merge or omit" |
| 15:11:08 | <djazayeri> but in either case, that should require confirmation (even for omit) |
| 15:11:13 | <djazayeri> basically that's a "conflict" |
| 15:11:50 | <rafa> So my suggestion is we will only have an option to "prefer merge" |
| 15:11:56 | <rafa> We'll omit by default |
| 15:12:28 | <djazayeri> I would prefer if we actually have a screen where the only question we ask is prefer omit (the default) vs prefer merge |
| 15:12:40 | <rafa> I see |
| 15:12:44 | <djazayeri> as radio buttons, and you click next to proceed. |
| 15:12:46 | <rafa> Okay |
| 15:13:00 | <rafa> It'll also work. |
| 15:13:11 | <djazayeri> so it's an explicit choice between "I trust myself more" (the default) and "I trust what I'm importing more" |
| 15:13:40 | <rafa> Good |
| 15:14:16 | <rafa> The last thing to decide is what we do with mapped things. |
| 15:14:35 | <djazayeri> so, things we mapped before, and are now importing a second version of |
| 15:14:38 | <rafa> I mean ones that do not have same uuids |
| 15:14:48 | <djazayeri> yes |
| 15:15:13 | <rafa> I think that if I choose map once, it should stay map in the next import and be confirmed |
| 15:15:31 | <djazayeri> What's the human interpretation of that? |
| 15:15:41 | <djazayeri> I have a WEIGHT-MINE concept |
| 15:15:45 | <djazayeri> I import a WEIGHT-THEIRS |
| 15:15:50 | <djazayeri> I choose "map" |
| 15:16:10 | <djazayeri> So, we're talking about the situation where I import WEIGHT-THEIRS again? |
| 15:16:25 | <rafa> yes |
| 15:16:41 | <rafa> for the first time we'll add mappings to WEIGHT-MINE |
| 15:17:02 | <rafa> for the second time WEIGHT-MINE will be used for everything in the package |
| 15:17:05 | <djazayeri> By "map" do you mean map-but-keep-mine? |
| 15:17:08 | <rafa> by default |
| 15:17:11 | <djazayeri> (as opposed to map-and-overwrite?) |
| 15:17:13 | <rafa> yes |
| 15:17:35 | *** dkayiwa has quit IRC |
| 15:17:47 | <djazayeri> Okay, I agree that if you chose map-and-keep-mine last time, that should persist. |
| 15:17:58 | <djazayeri> I mean, that should be the default if you get an update |
| 15:18:32 | <rafa> Will we ask to confirm based on dates? Or always confirm? |
| 15:18:36 | <djazayeri> Will we know the date modified of WEIGHT-THEIRS in the last import? |
| 15:18:49 | <rafa> Yes, we store that. |
| 15:19:32 | <rafa> So if we determine that the date modified has changed, we can actually ask to confirm |
| 15:19:40 | <rafa> Otherwise, mapping will be confirmed |
| 15:19:48 | <djazayeri> I agree with that |
| 15:20:08 | <djazayeri> the date modified is the same, confirm, otherwise ask. |
| 15:20:18 | <djazayeri> but still default to map-and-keep-mine |
| 15:20:22 | <rafa> Okay |
| 15:20:46 | <rafa> I think we can apply the same bahavior to map-and-overwrite |
| 15:21:32 | <rafa> Or maybe we should also look at existing date changed vs last import |
| 15:21:46 | *** vchircu has joined #openmrs |
| 15:22:02 | <djazayeri> so, the previous time I said map-and-overwite WEIGHT-MINE with WEIGHT-THEIRS |
| 15:22:09 | <djazayeri> then I get WEIGHT-THEIRS again. |
| 15:22:28 | <djazayeri> if the date-modified (for the previous import of WEIGHT-THEIRS vs the incoming one |
| 15:22:44 | <djazayeri> is the same -> could even omit, because in theory nothing has changed |
| 15:22:57 | <rafa> Oh right |
| 15:23:10 | <djazayeri> incoming is newer -> should overwrite |
| 15:23:25 | <djazayeri> (confirmation based on original global choice) |
| 15:23:49 | <djazayeri> existing is newer -> omit (require confirmation) ??? |
| 15:24:21 | <rafa> yes, it would be similarly to the case with same uuids |
| 15:24:36 | *** bwolfe has quit IRC |
| 15:25:59 | <rafa> I think it's right. |
| 15:26:12 | *** vchircu has quit IRC |
| 15:26:21 | <djazayeri> actually, in the existing is newer case, if you said "I trust this import" it should probably default to overwrite |
| 15:26:59 | <rafa> Correct as with same uuids |
| 15:27:06 | <djazayeri> ok |
| 15:28:32 | <rafa> What do we do with skip, if possible? |
| 15:28:50 | <djazayeri> In which case? |
| 15:29:02 | <rafa> In case no replacement was chosen |
| 15:29:06 | <djazayeri> second time, where the first time they said skip? |
| 15:29:37 | <rafa> so I just don't want to include the thing |
| 15:29:38 | *** jkeiper is now known as chopin |
| 15:30:07 | <djazayeri> I think default to skip (again) but require confirmation |
| 15:30:26 | <rafa> Agree |
| 15:31:07 | <rafa> That should be a rare case anyway. |
| 15:31:35 | <rafa> Mostly the item will be required by some other item and we will create it anyway |
| 15:32:26 | <rafa> So let's assume our first choice was create new |
| 15:32:34 | <rafa> What do we do the next time? |
| 15:32:57 | <rafa> It should be the same situation as with same uuids, right? |
| 15:33:08 | <djazayeri> i.e. depends on date modified? |
| 15:34:30 | <djazayeri> I think if the date-modified is equal, we can omit with no confirmation |
| 15:34:56 | <djazayeri> if incoming is newer, we overwrite (with confirmation depending on the global choice) |
| 15:36:20 | <djazayeri> if existing is newer, thenâ¦if I said "trust the import" then we merge with no confirmation. If I said "trust mine" we omit, with confirmation. |
| 15:36:58 | <djazayeri> (Is this decision tree getting too complicated? and perhaps inconsistent? maybe we need to put this in a google spreadsheet, or an etherpad doc) |
| 15:37:36 | <rafa> No it's okay, we're quite consistent :) |
| 15:37:52 | <rafa> I'm comparing with my notes actually. |
| 15:38:48 | <rafa> Perfect, that's it. |
| 15:40:04 | <djazayeri> great |
| 15:40:20 | <djazayeri> What's the state of the module now, btw? If I check it out will it run? |
| 15:40:35 | <djazayeri> I had a few trivial UI comments from the demo, e.g. some things need borders and shading. |
| 15:41:14 | <rafa> Yes, it'll run but you need OpenMRS 1.6.3 with a small fix to actually be able to finish importing. |
| 15:41:31 | <r-friedman> djazayeri: you're right, i'd say omit not merge |
| 15:41:34 | <rafa> I've issued a ticket for that fix. |
| 15:41:46 | <rafa> I'll back port it to all versions |
| 15:41:56 | *** downeym_ has joined #openmrs |
| 15:41:56 | *** ChanServ sets mode: +o downeym_ |
| 15:42:16 | <djazayeri> r-friedman: I hope it wasn't too painful to read that whole thread. |
| 15:42:26 | <rafa> :) |
| 15:42:37 | <r-friedman> rafa: it looks like a person can choose merge once, then map the next time around, so you have a map pointing to itself |
| 15:43:01 | <r-friedman> djazayeri: you're just a very transparent person, i only have to read half |
| 15:43:06 | <djazayeri> rafa: actually, looking back at the part that roger was referring to... |
| 15:43:17 | <djazayeri> I think we should make it depend on the global choice |
| 15:43:28 | <djazayeri> if they said "trust incoming" it defaults to merge |
| 15:43:33 | <djazayeri> if they said "trust mine" it defaults to omit |
| 15:43:42 | <djazayeri> does that make sense in that context? |
| 15:43:52 | <rafa> djazayeri: yes |
| 15:44:00 | <r-friedman> if i'm doing it, i trust mine, if you're doing it i trust incoming |
| 15:44:22 | <rafa> r-friedman: yes, you can choose map, but it won't hurt |
| 15:45:14 | <r-friedman> what about the next time? or what about adding imported cross-maps? |
| 15:45:28 | <rafa> r-friedman: map adds only mappings, which were added while merging anyway |
| 15:46:05 | <r-friedman> ok, so the import has a concept and its map to snomed |
| 15:46:21 | <r-friedman> the existing has a concept and its map to snomed |
| 15:46:42 | *** downeym has quit IRC |
| 15:46:42 | *** downeym_ is now known as downeym |
| 15:46:54 | <r-friedman> the first time it's merged, so the concept data and maps now look like the import |
| 15:47:22 | <r-friedman> the second time it's mapped, so that there's a map from the concept to the existing concept plus a map from snomed to the imported map |
| 15:48:30 | <r-friedman> assuming that we are modifying getConcept to follow mapping chains as well as id matches, won't we get multiple responses from the concept_map table when we expect a singleton? |
| 15:49:56 | <rafa> djazayeri: Darius, can you help me with that? I'm not that familiar with cross-maps. |
| 15:50:49 | <djazayeri> can we contrive an example for this r-friedman? |
| 15:51:19 | <r-friedman> ok, we have C1=long nosehair |
| 15:51:26 | <djazayeri> I have WEIGHT (with no maps). I import WEIGHT-MVP (which has maps to it's mvp id and snomed id) |
| 15:51:35 | <djazayeri> the first time I say "merge" |
| 15:51:56 | <djazayeri> so now I have WEIGHT-MVP (with 2 mappings, though it has my uuid, not theirs) |
| 15:52:13 | <r-friedman> ok so the existing WEIGHT has become WEIGHT_MVP and there's a map from WEIGHT (SNOMED) to WEIGHT_MVP |
| 15:52:28 | <r-friedman> now we import again and map |
| 15:52:47 | <r-friedman> do we still have WEIGHT? |
| 15:52:58 | <r-friedman> or only WEIGHT_MVP? |
| 15:53:05 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (trunk): Add checkstyle check for "new Date().getTime()" - TRUNK-1602... <http://feedproxy.google.com/~r/OMRStrunk/~3/lXc4bU8tgyw/OpenMRS> || New Changeset: OpenMRS (localize-setup-wizard): TRUNK-2055 : localized testingsetup.vm page and additional error messages for test installation <http://feedproxy.google.com/~r/OMRStrunk/~3/B45CNqZtb44/OpenMRS> || New Changeset: OpenMRS (trunk): Unable to Save New Concept in Indonesia Locale - TRUNK-2424 <http://feedproxy.google.com/~r/OMRStrunk/~3/8GYlCkdRLbI/OpenMRS> |
| 15:53:05 | <djazayeri> import it coming from whom? re-import the same package? import a new version from mvp? Import a form from someone else that includes an old version of the concpet? (does it matter?) |
| 15:53:38 | <r-friedman> yikes |
| 15:53:44 | <djazayeri> since we did the merge, we overwrote WEIGHT with WEIGHT-MVP. (rafa does it preserve both names?) |
| 15:53:59 | <r-friedman> hold on, phone call |
| 15:54:00 | <djazayeri> though it keeps the uuid of our original WEIGHT. |
| 15:54:03 | <djazayeri> okay |
| 15:54:04 | <rafa> yes, it does |
| 15:54:14 | <docpaul> :) |
| 15:54:18 | *** docpaul has left #openmrs |
| 15:54:30 | <djazayeri> btw, rafa "merge" is confusing terminology. It's merging the collections, but overwriting the properties |
| 15:54:31 | *** docpaul has joined #openmrs |
| 15:54:35 | <djazayeri> I'd prefer to call this overwrite. |
| 15:54:36 | *** ChanServ sets mode: +o docpaul |
| 15:55:05 | <docpaul> busy busy developers. :) |
| 15:55:10 | <r-friedman> do we need both "merge" and "replace"? |
| 15:55:36 | <djazayeri> r-friedman: the problem is that rafa is using "merge" to mean the idea of "replace" |
| 15:55:46 | <djazayeri> I think it should be called "overwrite" personally |
| 15:56:01 | <r-friedman> with replace, we're adopting the imported concept, we're hitching our wagon to that star and we're abandoning ours, we'll accept any imports from that source with the imported UUID |
| 15:56:03 | <djazayeri> the trickiness is that it overwrites simple properties, but merges collections. |
| 15:56:35 | <rafa> djazayeri: Yes, I've changed that to "overwrite" in the UI already. I just can't switch myselft to the "overwrite" term ;) |
| 15:57:04 | <r-friedman> with merge, we're keeping our concept but only adding a map to our concept and merging in collections |
| 15:57:15 | <djazayeri> roger's interpretation is natural though |
| 15:57:25 | <djazayeri> so let's please stop using the word "merge" |
| 15:57:37 | <djazayeri> r-friedman: we actually don't have an option that does what you describe |
| 15:58:00 | <r-friedman> of course, the collection members have to come in first before the collection because they too could match existing concepts |
| 15:58:33 | <djazayeri> what rafal calls "map" is what's in the UI as "map-but-keep-mine". This still does add the mapping though. |
| 15:59:00 | <djazayeri> There's no weaker mechanism to say "substitute mine for this, but do NOT add the mapping" |
| 15:59:27 | <djazayeri> There's the much stronger mechanism to say "map-and-overwrite-mine" (what rafa has been calling "merge") |
| 15:59:30 | <r-friedman> what are the downstream implications? is every object that references the concept being overwriten going to be edited? |
| 15:59:58 | <r-friedman> or will the concept id stay the same? |
| 16:00:13 | <djazayeri> every other object in the incoming metadata package will have "mine" substituted for the incoming item. |
| 16:00:36 | <djazayeri> In any of those cases the conceptId (or other pk for other metadata types) doesn't change |
| 16:00:39 | <djazayeri> neither does the uuid. |
| 16:00:45 | <djazayeri> so we don't need to change obs. |
| 16:01:17 | <djazayeri> If you were to have a numeric concept and you were to overwrite it with a text concept, this would cause obs to break. |
| 16:01:35 | *** mandric_ has joined #openmrs |
| 16:01:35 | <djazayeri> we're not currently preventing that, but we know where we'll eventually insert that in code, when we have time. |
| 16:01:36 | *** mandric has quit IRC |
| 16:01:36 | *** mandric_ is now known as mandric |
| 16:02:36 | <r-friedman> to make sure i understand: if incoming and existing have same uuid and i say overwrite then the existing payload is replaced by the incoming payload |
| 16:03:19 | <djazayeri> so, the very first logical branch is: is there an existing item with exactly the same uuid. |
| 16:03:19 | <r-friedman> or is change date logic involved here as well? |
| 16:03:42 | <djazayeri> If there is (i.e. these are the same object identity by defiinition)... |
| 16:04:00 | <djazayeri> yes, rafa proposed some date changed logic. let me look back up for it |
| 16:04:11 | <r-friedman> (the little mysql problem notwithstanding) |
| 16:04:48 | <djazayeri> indeed, notwithstanding that |
| 16:05:16 | <djazayeri> basically the proposal is that we go based on dateModified. (It's not perfect, because of last-change-wins issues, but we don't have a better way) |
| 16:05:56 | <djazayeri> Further, I've said that the very first step of the import should be to ask you to choose between "trust my existing items" (the default) or "trust the import" |
| 16:06:22 | <djazayeri> the latter option is for people who are trying to centrally push out metadata changes to other sites they control |
| 16:06:45 | <djazayeri> the former is for people who are sharing metadata across ownership/control boundaries. |
| 16:06:47 | <r-friedman> it's worse than last change wins. it means that significant local changes have to cause the uuid to change |
| 16:07:36 | <r-friedman> you can only make significant changes on the machine that is the source |
| 16:07:50 | <djazayeri> but this is peer to peer |
| 16:08:00 | <djazayeri> we don't actually know the original source |
| 16:08:13 | <djazayeri> and we have no control once someone else imports it |
| 16:08:27 | <r-friedman> i thought we were keeping all source chains |
| 16:08:47 | <djazayeri> (I agree that what you're saying would be a nice feature, but I don't see how we can provide it via metadata sharing.) |
| 16:09:22 | <r-friedman> i think it's key to what you were saying about accepting a form with an old version of a concept |
| 16:09:44 | <djazayeri> I don't think you can tell whether something is originally yours or not. |
| 16:10:11 | <r-friedman> anything you change is yours -- you break it, you own it |
| 16:10:12 | <djazayeri> and even if you knew it wasn't, there's no real way for the module to prevent you from modifying it in the concept dictionary if you want |
| 16:11:08 | <r-friedman> right, it's just no longer the concept it used to be |
| 16:11:23 | <djazayeri> okay, but that's a bigger issue than just metadata sharing |
| 16:11:50 | <r-friedman> it's the same issue rearing its ugly head in a different context |
| 16:12:09 | <djazayeri> i.e. if changing a concept's datatype needs to change its uuid, probably it will break obs, so we need a way to prevent this. |
| 16:12:20 | <djazayeri> but it's not rafal's problem to solve in this module version. |
| 16:12:43 | <r-friedman> yah, can we have a version in concept map? |
| 16:12:53 | <r-friedman> or concept source? |
| 16:13:21 | <r-friedman> so that if I have received MVP version 6 and i receive a form with MVP version 5 then I know I can use 6 with no problem |
| 16:13:36 | <djazayeri> interesting suggestion |
| 16:14:26 | <djazayeri> so, we'd previous decided that you have something like "Local Dictionary: Darius's Laptop" -> 5089, or "MVP" -> 1234 |
| 16:14:40 | <djazayeri> (those are the "tracking" mappings) |
| 16:14:51 | <r-friedman> right, and we version that |
| 16:14:56 | <djazayeri> you're suggesting that could be "MVP" -> "1234 v5" |
| 16:15:07 | <djazayeri> (or something like that) |
| 16:15:36 | <r-friedman> i'm a little concerned with having versions at the source level -- probably a good idea but a little abstruse |
| 16:15:39 | <djazayeri> so, concepts aren't currently versioned. |
| 16:15:53 | <djazayeri> well, they may be |
| 16:16:02 | <djazayeri> I'm proposing the version is in the *mapping* not the source |
| 16:16:15 | <djazayeri> so, there _is_ a version property on concept, but I don't know if people use it. |
| 16:16:20 | <djazayeri> (gotta run for a few) |
| 16:16:33 | <r-friedman> ok, ping me when you get back |
| 16:19:26 | *** chopin has quit IRC |
| 16:23:14 | <wyclif> djazayeri, after some careful thinkink about https://tickets.openmrs.org/browse/TRUNK-2426 |
| 16:24:25 | <wyclif> i still think the new logic can still end up with duplicate order number in an extreme situation |
| 16:24:33 | <wyclif> mark 'EXTREME' |
| 16:30:37 | *** vchircu has joined #openmrs |
| 16:30:53 | <wyclif> on 2 application restarts, you are always going to have the same order number returned provided no new orders get saved between the restarts |
| 16:31:45 | <wyclif> so if it happens that a client calls the openmrs server for the next order id and them before it can make a request to save the order, the application is restarted meaning our static variable for order number is reset, so the subsequent call to get order number will return the very |
| 16:32:29 | <wyclif> sorry return a duplicate |
| 16:33:02 | <wyclif> and is the two calls are made for separate orders, then they will have duplicates |
| 16:33:56 | *** chopin has joined #openmrs |
| 16:36:38 | <wyclif> djazayeri, the work around could be to actually save it as a global property so that each time we call getNewOrderNumber, we persist the new value before returning |
| 16:41:54 | *** deadpool has joined #openmrs |
| 16:45:40 | *** guduji has quit IRC |
| 16:50:34 | *** rafa has quit IRC |
| 16:51:34 | <djazayeri> wyclif: the client should not be asking for an ordernumber |
| 16:51:40 | <djazayeri> it should be assigned when you save the order |
| 16:52:02 | *** cta has joined #openmrs |
| 16:52:06 | <cta> hello |
| 16:52:29 | <djazayeri> there's an edge case around fetching the next available order number from the database the first time you create an order |
| 16:52:44 | *** vchircu has quit IRC |
| 16:53:05 | <djazayeri> but the solution there is to just do that at application startup in a synchronized static block |
| 16:53:56 | <djazayeri> wyclif: just put javadoc on the getNextOrderNumber saying "this method is only intended to be used by OpenMRS internally. Client or module code should *not* use it" |
| 16:54:22 | <djazayeri> r-friedman: back |
| 16:54:36 | <r-friedman> hey |
| 16:54:38 | *** vchircu has joined #openmrs |
| 16:55:05 | <r-friedman> so there's a version in concept. we could take that over. |
| 16:55:09 | <OpenMRSBot> Recent updates in the world of openmrs: On Twitter: OpenMRS: RT @mwatha: @baobabhealth Bart app is now running on top of openmrs 1.7 .. @bawolfe this is so now :) <http://twitter.com/OpenMRS/statuses/86828608945012736> |
| 16:55:26 | <djazayeri> though in my experience people don't use concept.version at all |
| 16:55:37 | <djazayeri> (it needs to be manually changed) |
| 16:56:15 | <r-friedman> but i can easily see a protocol that could be used by curated repositories |
| 16:56:41 | <djazayeri> yes. |
| 16:56:44 | <r-friedman> doesn't help us with locations, though -- your state list example |
| 16:56:59 | <djazayeri> what we should really do is see whether Andy is currently keeping track of Version in the MVP dictionary |
| 16:57:06 | <djazayeri> if not, let's get him started. |
| 16:57:12 | <djazayeri> If so, let's see if we can leverage that. |
| 16:58:03 | <r-friedman> we should probably have a versoin in concept source as well |
| 16:58:22 | <r-friedman> it would be the front end of the full version kept in concept |
| 16:58:34 | <djazayeri> Currently I think people would have sources for "ICD-9" and "ICD-10" |
| 16:58:57 | <djazayeri> sources are only used for mappings though, not for local concepts |
| 16:58:58 | <r-friedman> plus MDR-TB example ... we are building it into HR Module as well |
| 16:59:28 | <r-friedman> you can't export metadata without having a local source id |
| 16:59:48 | <r-friedman> (unless you're only exporting others' concepts) |
| 17:00:49 | <r-friedman> i don't know what rafa's import history table looks like, maybe it could serve for all objects |
| 17:01:28 | <djazayeri> I think it's just class, uuid, (optional) local replacement uuid, last-date-imported |
| 17:01:52 | <r-friedman> so we add source and version |
| 17:02:04 | <r-friedman> source overlaps with concept source but includes other objects |
| 17:02:31 | <djazayeri> do a full history instead of just keeping the latest import? |
| 17:02:43 | <r-friedman> when we export our own objects, we count them as having been imported on the date of the export |
| 17:02:47 | <djazayeri> Makes sense. I'd need to wrap my head around it more. |
| 17:03:10 | <r-friedman> we don't need a full history i don't think |
| 17:03:46 | <r-friedman> so while you wrap your head around it, could you tell me what you had to do to handle the embedded objects in htmlforms? |
| 17:03:50 | <djazayeri> why does exporting an object count it as imported? |
| 17:04:16 | <djazayeri> is it because exporting an object means that you've "published" it? |
| 17:04:25 | <r-friedman> can't tell whether it arrived and was created or was created, machs nichts i think |
| 17:04:49 | <djazayeri> so, about htmlforms |
| 17:04:56 | <r-friedman> the important thing is to version the local objects |
| 17:05:10 | <djazayeri> the problem was to deal with the xml blob that says <obs conceptId="5089"/> |
| 17:05:32 | <djazayeri> because when you export that, 5089 becomes meaningless. |
| 17:06:16 | <r-friedman> the solution? |
| 17:06:18 | <djazayeri> The original approach Mark took was when we do the export, you convert that to <obs conceptId="some-long-uuid"/> and also include it in the manual "getDependencies" method or whatever we called it. |
| 17:06:53 | <djazayeri> That's still the approach, but since then we've also added the ability to say <obs conceptId="SNOMED:some-code"/> |
| 17:07:41 | <r-friedman> so can you generalize that to an interface? |
| 17:07:43 | <djazayeri> and with this additional mapping work we're doing, what we *could* do would be instead of replacing with the uuid, we replace with the mapping in the "local" source. |
| 17:08:25 | <djazayeri> The idea of being able to do extra on-export and on-import work for a metadata item is already generalized. |
| 17:08:48 | <djazayeri> for example xforms should be able to do the same thing |
| 17:08:55 | <djazayeri> I haven't worked with Daniel on that yet though. |
| 17:09:37 | <r-friedman> I'm thinking a lot about the new attribute model and complex concepts |
| 17:27:17 | *** chopin has quit IRC |
| 17:39:51 | *** chopin has joined #openmrs |
| 17:42:17 | *** bwolfe has joined #openmrs |
| 17:42:17 | *** ChanServ sets mode: +o bwolfe |
| 17:43:12 | <vchircu> hey guys, I'm having some trouble here and maybe you can help me |
| 17:43:41 | <vchircu> when I'm trying to build the OpenMRS web app it fails because it can't load the logic module |
| 17:44:14 | <vchircu> this is because it tries to create the logic module related tables in the DB, but they already exist |
| 17:44:30 | <djazayeri> vchircu: what openmrs version? |
| 17:44:34 | <vchircu> as a note, I'm working with the 1.9.0 snapshot, and I'm building a module |
| 17:44:43 | <vchircu> so I haven't change any of the trunk related code |
| 17:44:57 | <djazayeri> does it mention a liquibase changeset? or xml? |
| 17:45:22 | *** mathiaslin has quit IRC |
| 17:46:19 | <vchircu> 01-Jul-2011 20:25:57 liquibase.lock.LockHandler releaseLock INFO: Successfully released change log lock WARN - ModuleFactory.startModuleInternal(603) |2011-07-01 20:25:58,318| Error while trying to start module: logic org.openmrs.api.db.DAOException: Error while running sql: CREATE TABLE `logic_rule_definition` (..) ENGINE=InnoDB DEFAULT CHARSET=utf8 . Message: Table 'logic_rule_definition' already exists at org.openmrs.util.Databa |
| 17:47:34 | *** rafa has joined #openmrs |
| 17:47:34 | *** ChanServ sets mode: +v rafa |
| 17:48:08 | <djazayeri> vchircu: what is the value of your global property logic.database_version |
| 17:52:06 | <vchircu> 1.0.0 |
| 18:00:21 | <djazayeri> vchircu: we see this error *a lot* |
| 18:00:27 | <djazayeri> but I don't know where it comes from |
| 18:00:40 | <djazayeri> because all the tagged versions of the logic module in svn do _not_ create this |
| 18:01:57 | <vchircu> djazayeri: so what could be a work around ? |
| 18:02:21 | <djazayeri> If the table is empty, (or if you don't care what's in it) drop it |
| 18:02:23 | <vchircu> deleting the table directly from the DB ? |
| 18:02:30 | <vchircu> ok |
| 18:02:32 | <djazayeri> what logic_* tables do you have? |
| 18:02:36 | <vchircu> I'll do that |
| 18:02:47 | <djazayeri> can you check via mysql workbench or something? I'm curious to know. |
| 18:03:37 | <vchircu> djazayeri: rule_definition, rule_token, rule_token_tag, rule_token_registration, rule_token_registration_tag |
| 18:05:00 | <djazayeri> hmmâ¦did you ever run the rest web service module? |
| 18:05:13 | <vchircu> no, never |
| 18:05:28 | <djazayeri> what have you done so far, historically, with your database to get to this point? |
| 18:05:39 | <djazayeri> is it a recent install? or one with history? |
| 18:05:48 | <vchircu> nothing in particular |
| 18:05:53 | <vchircu> it is a recent install |
| 18:06:15 | <vchircu> I'm working on the atlas module, and the properties will be saved as global properties |
| 18:06:16 | <djazayeri> Do you remember what OpenMRS version you installed at? |
| 18:06:29 | <vchircu> 1.9.0 |
| 18:06:47 | <vchircu> I think I installed it about 2 months ago |
| 18:06:48 | <djazayeri> hmmâ¦are you aware of the danger of calling saveGlobalProperties(List<GlobalProperty>)? |
| 18:06:52 | <djazayeri> i.e. have you ever done that? |
| 18:07:01 | <vchircu> yes |
| 18:07:05 | <vchircu> I have done that |
| 18:07:12 | *** yanokwa has quit IRC |
| 18:07:14 | <djazayeri> are you aware that that erases all global properties except for the ones you pass in? |
| 18:07:36 | <vchircu> no |
| 18:07:38 | <djazayeri> Basically that method is bad, and dangerous, and it's not documented in an obvious way. |
| 18:07:56 | <vchircu> so that's the problem |
| 18:07:56 | <djazayeri> It should never be used, except for on the "Manage Global Properties" page where it's actually saving all of them. |
| 18:07:59 | <djazayeri> So, that's the problem. |
| 18:08:04 | <djazayeri> We really need to deal with that. |
| 18:08:16 | <vchircu> I thought it would save a list of props |
| 18:08:36 | <djazayeri> That makes perfect sense. |
| 18:08:36 | <vchircu> thanks Darius |
| 18:08:40 | <djazayeri> Your interpretation, I mean. |
| 18:08:47 | <djazayeri> It's a really annoying bug in core. |
| 18:09:07 | <vchircu> and now, how can I restore the global properties table ? |
| 18:09:21 | <djazayeri> do you care what's in your database? |
| 18:09:27 | <djazayeri> can you just nuke the whole thing? |
| 18:09:28 | <vchircu> no |
| 18:09:33 | <vchircu> yes |
| 18:09:37 | <djazayeri> In that case, that's probably easiest. |
| 18:09:41 | <vchircu> I mean, I don't care |
| 18:09:54 | <vchircu> ok, I'll do that |
| 18:10:01 | <vchircu> thanks again for the help |
| 18:10:04 | <djazayeri> drop the database, delete your .OpenMRS/openmrs-runtime.properties file, and restart the webapp |
| 18:10:05 | <djazayeri> np |
| 18:10:19 | <djazayeri> bwolfe: do you know if there's a ticket for fixing the (evil) saveGlobalProperties(List) method? |
| 18:10:24 | *** bwolfe has quit IRC |
| 18:16:41 | *** james_regen has quit IRC |
| 18:16:42 | *** vchircu has quit IRC |
| 18:32:49 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (localize-setup-wizard): TRUNK-2055 : fixed after review comments <http://feedproxy.google.com/~r/OMRStrunk/~3/lJ-bnTwWv04/OpenMRS> |
| 18:33:34 | *** rafa has quit IRC |
| 18:56:30 | *** mandric has quit IRC |
| 18:56:48 | *** mandric has joined #openmrs |
| 18:58:25 | *** yanokwa has joined #openmrs |
| 18:58:25 | *** ChanServ sets mode: +v yanokwa |
| 19:11:49 | *** yanokwa has quit IRC |
| 19:22:58 | <r-friedman> djazayeri: you here? |
| 19:23:08 | <djazayeri> yes |
| 19:23:22 | <r-friedman> djazayeri: just looking at your post with C Zakian |
| 19:23:37 | <r-friedman> isn't there a regular way for a module to add its own objects to the hibernate session? |
| 19:23:46 | <djazayeri> That's not what he wants to do |
| 19:24:02 | <djazayeri> he's looking at changing the underlying hibernate configuration, e.g. to add the hibernate-search plugin |
| 19:24:18 | <djazayeri> or something like that, but I don't know the details. |
| 19:24:34 | <djazayeri> (I should have just asked him what he wanted to do exactly, rather than suggesting an inappropriate solution and saying don't use it.) |
| 19:24:46 | <r-friedman> oh, i was reading about that yesterday, you can just go ahead and set it in core, it imposes no burden unless it's actually used |
| 19:25:07 | <djazayeri> good to know, want to say that on the email thread? |
| 19:25:24 | <r-friedman> sure, get some community validation :) |
| 19:37:43 | *** downeym_ has joined #openmrs |
| 19:37:43 | *** ChanServ sets mode: +o downeym_ |
| 19:41:33 | *** downeym has quit IRC |
| 19:41:33 | *** downeym_ is now known as downeym |
| 19:55:21 | *** bwolfe has joined #openmrs |
| 19:55:21 | *** ChanServ sets mode: +o bwolfe |
| 19:55:22 | *** bwolfe has quit IRC |
| 19:55:42 | *** bwolfe has joined #openmrs |
| 19:55:42 | *** ChanServ sets mode: +o bwolfe |
| 20:05:37 | *** docpaul has quit IRC |
| 20:06:41 | *** r-friedman has quit IRC |
| 20:15:23 | *** gbastien has quit IRC |
| 20:29:31 | *** rafa has joined #openmrs |
| 20:29:38 | *** ChanServ sets mode: +v rafa |
| 20:44:39 | <cta> bye guys |
| 20:44:45 | *** cta has quit IRC |
| 20:52:51 | *** chopin has quit IRC |
| 20:53:11 | <djazayeri> downeym: are we going to have an Unsupported Modules JIRA project before the long weekend? |
| 20:53:24 | <djazayeri> Or am I going to forget to check in my code on Tuesday? |
| 20:53:27 | <djazayeri> :-) |
| 21:18:37 | *** guduji has joined #openmrs |
| 21:20:09 | *** bwolfe has quit IRC |
| 21:20:18 | *** mandric has quit IRC |
| 21:21:19 | *** rafa has quit IRC |
| 21:49:10 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (order-entry): Follow up to Move assignment of orderNumber into OrderSaveHandler - TRUNK-2426 <http://feedproxy.google.com/~r/OMRStrunk/~3/BlEmkHq4F4Q/OpenMRS> |
| 21:52:11 | *** wluyima has joined #openmrs |
| 21:52:11 | *** wyclif has quit IRC |
| 22:00:39 | *** downeym has quit IRC |
| 22:07:34 | *** mandric has joined #openmrs |
| 22:24:22 | *** wluyima has quit IRC |
| 22:37:44 | *** yanokwa has joined #openmrs |
| 22:37:44 | *** ChanServ sets mode: +v yanokwa |
| 22:53:15 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (order-entry): Adding missing precondition and comment for changeset that restores foreign key constraint on drug_order.order_id <http://feedproxy.google.com/~r/OMRStrunk/~3/nnUMuaK6JH8/OpenMRS> || New Changeset: OpenMRS (trunk): PatientSearch objects with filterClass belonging to a module aren't always properly decoded - TRUNK-2435 <http://feedproxy.google.com/~r/OMRStrunk/~3/-ofwz7S3K0w/OpenMRS> || New Changeset: OpenMRS (1.7.x): PatientSearch objects with filterClass belonging to a module aren't always properly decoded - TRUNK-2435 <http://feedproxy.google.com/~r/OMRStrunk/~3/xCoQPx4KKfI/OpenMRS> || New Changeset: OpenMRS (1.6.x): PatientSearch objects with filterClass belonging to a module aren't always properly decoded - TRUNK-2435 <http://feedproxy.google.com/~r/OMRStrunk/~3/ld0YaynXjw4/OpenMRS> || New Changeset: OpenMRS (1.8.x): PatientSearch objects with filterClass belonging to a module aren't always properly decoded - TRUNK-2435 <http://feedproxy.google.com/~r/OMRStrunk/~3/ILfDWwL4WU8/OpenMRS> || New Changeset: OpenMRS (order-entry): Removing the deprecated ORDER_STATUS enumeration and removing references to it <http://feedproxy.google.com/~r/OMRStrunk/~3/lCYHo1HtYqE/OpenMRS> |
| 23:21:00 | *** wluyima has joined #openmrs |
| 23:44:26 | *** guduji has quit IRC |
| 23:57:18 | <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS (order-entry): followup fix for TRUNK-2371 (should create a new ConceptClass for Order Set if we don't have one with the proper UUID, i... <http://feedproxy.google.com/~r/OMRStrunk/~3/J38WHI31f8Q/OpenMRS> || New Changeset: OpenMRS (order-entry): refactoring for TRUNK-2426 (moved some logic from the DAO to the Service layer) <http://feedproxy.google.com/~r/OMRStrunk/~3/_VdjerjSlRQ/OpenMRS> |