| 00:00:12 | <LeeBreisacher1> wyclif: Darius said he's going out to run an errand |
| 00:00:26 | <LeeBreisacher1> wyclif: said he'd be back in about 45 min |
| 00:00:27 | <wyclif> LeeBreisacher1: ok thanks |
| 00:00:36 | <wyclif> LeeBreisacher1: cool |
| 00:00:59 | <LeeBreisacher1> wyclif: I've been having troubles getting refdemodata to start properly |
| 00:00:59 | *** ciaron has quit IRC |
| 00:01:21 | <LeeBreisacher1> wyclif: I get a NPE in User.getAllRoles when trying to create the "clerk" user |
| 00:02:15 | <LeeBreisacher1> wyclif: sortof looks like the clerk role isn't in the db. might be a module-startup-order problem? |
| 00:02:35 | <LeeBreisacher1> wyclif: when is the clerk role added to the db, I can't find it. |
| 00:06:47 | <wyclif> LeeBreisacher1: from the demo date activator |
| 00:07:20 | <wyclif> LeeBreisacher1: referencedemodata module's activator |
| 00:07:46 | <wyclif> LeeBreisacher1: i know what causes that |
| 00:07:53 | <LeeBreisacher1> wyclif: I don't see it. I see this: |
| 00:07:53 | <LeeBreisacher1> Role clerkRole = userService.getRoleByUuid(ReferenceDemoDataConstants.CLERK_ROLE_UUID); |
| 00:08:07 | <wyclif> LeeBreisacher1: i know the bug that causes that |
| 00:08:21 | <LeeBreisacher1> wyclif: please explain (if it's short..) |
| 00:08:43 | <wyclif> LeeBreisacher1: that happens sometimes the very first time you install the ref app with demo data and this is what causes it |
| 00:09:01 | <wyclif> refmetadata module is the one that is supposed to install those roles |
| 00:09:47 | <LeeBreisacher1> wyclif: right, but I see where it installs the clerk *provider* role, but not the clerk role |
| 00:09:59 | <wyclif> LeeBreisacher1: so the problem is |
| 00:11:10 | <wyclif> LeeBreisacher1: right now the module engine starts modules in random order, there is currently no way to control |
| 00:13:43 | <wyclif> so since refmetadata is the one that adds the roles, if ref demo data gets started before it ref metadata the very first time you install the ref app, it means the roles don't exist yet hence the NPE |
| 00:15:44 | <LeeBreisacher1> wyclif: I see. so just restarting should fix it. |
| 00:16:46 | <wyclif> LeeBreisacher1: yes, the next time you run it it should not occur because they already exist |
| 00:17:27 | <LeeBreisacher1> wyclif: except restarting caused some other problem to appear. a classNotFound exception. but now I wiped my vm and starting from scratch again. bleh. |
| 00:17:50 | <djazayeri> LeeBreisacher1, wyclif: I'm back no |
| 00:17:52 | <djazayeri> now |
| 00:25:03 | <wyclif> djazayeri: i just thought of another solution for issues we run into because modules are started in random order |
| 00:25:44 | <wyclif> djazayeri: why don't we make demo data use event module to be notified as ref metadata saves items |
| 00:26:18 | <wyclif> djazayeri: only thing to do is to add a listener to demo data module and then move the code that does whatever it does in the listener |
| 00:31:26 | <wyclif> djazayeri: what do you think? |
| 00:34:39 | <djazayeri> wyclif: I really think there must be a quick-fix to the ticket about module startup order |
| 00:35:10 | <wyclif> djazayeri: i think that ticket can be buggy if we try to rush it in right now before we release |
| 00:35:13 | <djazayeri> wyclif: I see that arkadiusz is working on them as if there's a dependency, but I don't see why we can simply set a "moduleStartupOrder" variable when starting modules, and then use that ordering to call the activators. |
| 00:37:14 | <LeeBreisacher1> djazayeri: ok, I finally have a working vm. when I look up a demo patient, then click on the name, I see this error in the log: |
| 00:37:14 | <LeeBreisacher1> .EcmaError: TypeError: Cannot read property "active" from null |
| 00:37:47 | <wyclif> djazayeri: my view here is that the event bus comes in handy here where you depend on data as it gets inserted |
| 00:38:01 | <LeeBreisacher1> djazayeri: I assume that means the demo patients are not quite correct yet. |
| 00:38:06 | <djazayeri> wyclif: I agree that the event solution would work, I just think a fix in core is better |
| 00:39:23 | *** robbyoconnor has quit IRC |
| 00:41:07 | <wyclif> djazayeri: up to now i still think that modules specifying start up order will definitely result into inconsistencies |
| 00:42:15 | <djazayeri> wyclif: in this case it's straightforward. refdemodata depends on refmetadata, therefore it should start up after |
| 00:44:03 | <wyclif> djazayeri: yes i know here it is straight forward in any case demo data modules is not production code, i just didn't want to wait for that ticket because i still find it very controversial |
| 00:45:10 | <djazayeri> wyclif: it shouldn't be controversial for module activators to be called in the same order the modules are started... |
| 00:46:18 | <wyclif> djazayeri: what i mean is that module A to say i start after module B is what that ticket is about and i think that will lead us into bad things |
| 00:46:40 | <wyclif> djazayeri: not for this use case i mean in general if we implement it in the future |
| 00:47:29 | <djazayeri> wyclif: I'm talking about https://tickets.openmrs.org/browse/TRUNK-3922 |
| 00:48:04 | <djazayeri> wyclif: for some reason it's marked as depending on TRUNK-4004 |
| 00:48:09 | <wyclif> djazayeri: that is to me can also lead to the same problem |
| 00:48:11 | <djazayeri> wyclif: which I think is wrong |
| 00:48:34 | <wyclif> djazayeri: i still think we can never depend on modules start up order |
| 00:48:40 | <djazayeri> wyclif: there is absolutely no reason why calling activator methods in the same order as the module's art loaded is a bad thing |
| 00:48:55 | <djazayeri> wyclif: (and shutting them down in reverse order) |
| 00:51:09 | <wyclif> djazayeri: want to skype |
| 00:51:25 | <djazayeri> wyclif: give me 5 minutes to see if I can write a quick patch for this... |
| 00:51:30 | <wyclif> djazayeri: ok |
| 00:56:33 | <LeeBreisacher1> djazayeri: let me know when you guys are done. I have more questions.. |
| 01:06:33 | <djazayeri> wyclif: running unit tests now |
| 01:06:40 | <djazayeri> LeeBreisacher1: question away |
| 01:07:30 | <LeeBreisacher1> djazayeri: when I look at a demo patient using the refapp, I see this error in the log: TypeError: Cannot read property "active" from null |
| 01:07:51 | <LeeBreisacher1> djazayeri: I assume that means I'm not quite creating the demo patients just right |
| 01:07:58 | <djazayeri> LeeBreisacher1: sounds to me like somehow there's an active visit variable that's null? |
| 01:08:07 | <djazayeri> LeeBreisacher1: is there a stacktrace? or just that message? |
| 01:08:34 | <LeeBreisacher1> djazayeri: there is a long stack trace |
| 01:08:41 | <LeeBreisacher1> djazayeri: with Rhino at the top |
| 01:08:54 | <djazayeri> LeeBreisacher1: can you give me a few lines of it that have org.openmrs in them? |
| 01:09:17 | <djazayeri> LeeBreisacher1: can you verify that this happens for your created demo patients and not for "regular" patients? |
| 01:09:29 | <LeeBreisacher1> djazayeri: yes, verified that |
| 01:09:52 | <LeeBreisacher1> djazayeri: how about AppFrameworkServiceImpl.getExtensionsForCurrentUser |
| 01:10:00 | <LeeBreisacher1> djazayeri: line 184 |
| 01:12:32 | <djazayeri> LeeBreisacher1: so, this must be coming from the code that evaluates extensions that have a "required" property which is a js expression to be evaluated against the page's "context model" |
| 01:13:06 | <djazayeri> LeeBreisacher1: basically the patient dashboard is supposed to have a context model that includes: visit: { id: x, active: true/false } |
| 01:13:15 | <djazayeri> LeeBreisacher1: but I guess somehow that isn't happening |
| 01:13:25 | <djazayeri> LeeBreisacher1: you're in the VM now, right, so you can't add a breakpoint? |
| 01:13:40 | <LeeBreisacher1> djazayeri: right |
| 01:13:55 | <LeeBreisacher1> djazayeri: I could just forge ahead and create Visits and such.. |
| 01:14:21 | <LeeBreisacher1> djazayeri: just thought I'd check that the patients I've created are valid |
| 01:14:21 | <djazayeri> LeeBreisacher1: if you look at a "regular" patient who has no visits, do you get the same error? |
| 01:14:48 | <LeeBreisacher1> djazayeri: no, a patient I just created does not have that error |
| 01:15:02 | <LeeBreisacher1> djazayeri: pretty sure. I could double check.. |
| 01:15:10 | <LeeBreisacher1> djazayeri: I mean a patient I registered |
| 01:15:42 | <djazayeri> LeeBreisacher1: hmm, okay |
| 01:15:44 | <LeeBreisacher1> djazayeri: maybe the register-patient app does something at the end |
| 01:15:55 | <djazayeri> LeeBreisacher1: It's not supposed to... |
| 01:16:08 | <djazayeri> LeeBreisacher1: if your code is committed, I could peek at it. |
| 01:16:30 | <LeeBreisacher1> djazayeri: not committed yet because I was trying to verify it's working right first! |
| 01:16:46 | <LeeBreisacher1> djazayeri: I could disable it (comment it out) and commit... |
| 01:19:31 | <djazayeri> wyclif: I just attached my patch to https://tickets.openmrs.org/browse/TRUNK-3922 |
| 01:19:45 | <djazayeri> wyclif: I haven't actually tested the behavior I added, but it doesn't break any existing unit tests. |
| 01:20:05 | <djazayeri> LeeBreisacher1: if the code is not called during normal operation of the system, I think you can just commit it. |
| 01:20:28 | <djazayeri> LeeBreisacher1: because normally the GP is not going to be set, so normally your code won't run, unless someone is explicitly invoking it, right? |
| 01:20:43 | <djazayeri> wyclif: what do you think of this? |
| 01:21:31 | <LeeBreisacher1> djazayeri: uh..the GP is created here and explicitly set to 100. I thought that was the idea.. |
| 01:21:49 | <djazayeri> LeeBreisacher1: no, sorry, I misspoke earlier. The default value of the GP should be 0. |
| 01:21:51 | <wyclif> djazayeri: i still don't think we should try to control module startup order in any way because it will be inconsistent even with that |
| 01:22:12 | <djazayeri> LeeBreisacher1: the only time we want to invoke it is if the standalone (or the administrator) sets the GP. |
| 01:22:28 | <djazayeri> wyclif: I really really don't understand why you feel that way. |
| 01:22:38 | <LeeBreisacher1> djazayeri: ah. makes sense. ok. I'll change it to zero and commit.. |
| 01:22:55 | <djazayeri> wyclif: modules define constraints on startup order, by declaring module dependencies |
| 01:23:16 | <LeeBreisacher1> djazayeri: wyclif: fwiw, I agree with D -- what's wrong with starting modules in the same order they were loaded? (if that's what we're talking about doing) |
| 01:23:22 | <wyclif> djazayeri: do you want to skype |
| 01:23:28 | <djazayeri> wyclif: for any given set of modules and dependencies, we should be able to calculate >=1 acceptable startup orders that satisfy the dependencies |
| 01:23:48 | <wyclif> djazayeri: or hangout with lee too |
| 01:23:55 | <djazayeri> wyclif: as long as we call the activator contextRefreshed + started methods in that order, I see no problems |
| 01:24:12 | <djazayeri> wyclif: sure, let's hangout, and if LeeBreisacher1 wants to join, he can |
| 01:24:31 | <wyclif> djazayeri: my issues is that i don't believe we should control that order, i want to leave it random |
| 01:24:38 | <LeeBreisacher1> djazayeri: shrug. I'd rather spend time on this demo patient stuff |
| 01:24:50 | <djazayeri> LeeBreisacher1: okay, save yourself. :-P |
| 01:25:03 | <wyclif> no problem LeeBreisacher1 |
| 01:25:06 | <djazayeri> wyclif: but we actually _do_ start the modules up in a particular order, and this is defined by dependencies |
| 01:25:29 | *** cospih_ has quit IRC |
| 01:25:30 | <wyclif> LeeBreisacher1: let try to hustle djazayeri about this :) |
| 01:26:04 | <LeeBreisacher1> wyclif: ?? I was agreeing with Darius! |
| 01:28:45 | <wyclif> djazayeri: ?? |
| 01:28:54 | <djazayeri> wyclif: ?? what? |
| 01:29:06 | <wyclif> djazayeri: still want a quick hangout |
| 01:29:15 | <wyclif> djazayeri: or skype |
| 01:29:21 | <djazayeri> wyclif: sure, or skype, whichever. I'm online in both, so call me. |
| 01:29:26 | <wyclif> djazayeri: i will try to make it quick |
| 01:36:20 | <LeeBreisacher1> djazayeri: I pushed my WIP to github |
| 01:46:45 | <djazayeri> LeeBreisacher1: I'll take a look in a few minutes |
| 01:47:08 | <LeeBreisacher1> djazayeri: I'm just proceeding with creating demo visits and all |
| 01:47:39 | <LeeBreisacher1> djazayeri: hoping the problem will go away when patients have actual visits |
| 01:50:34 | *** robbyoconnor has joined #openmrs |
| 01:50:34 | *** ChanServ sets mode: +v robbyoconnor |
| 01:55:08 | *** robbyoconnor has quit IRC |
| 02:04:40 | *** robbyoconnor has joined #openmrs |
| 02:04:40 | *** ChanServ sets mode: +v robbyoconnor |
| 02:04:40 | *** robbyoconnor has quit IRC |
| 02:13:25 | <LeeBreisacher1> djazayeri: adding visits to each patient did not fix the "Cannot read property 'active' from null" error |
| 02:16:09 | *** harsz89 has joined #openmrs |
| 02:16:22 | *** ChanServ sets mode: +v harsz89 |
| 02:28:43 | <djazayeri> LeeBreisacher1: I made some comments on the commit, but nothing in there looks like it should cause an error to be logged. |
| 02:28:56 | <LeeBreisacher1> djazayeri: I saw. thanks. |
| 02:29:05 | *** wyclif has quit IRC |
| 02:29:37 | <LeeBreisacher1> djazayeri: guess I'll have to debug it |
| 02:30:12 | <djazayeri> LeeBreisacher1: are you absolutely sure that if you create a regular patient through the UI, with no visits, it doesn't also log this error? |
| 02:30:40 | <LeeBreisacher1> djazayeri: not 100%. trying it... |
| 02:32:18 | <djazayeri> LeeBreisacher1: the relevant line of code for logging this error is |
| 02:32:19 | <djazayeri> log.error("Failed to evaluate 'require' check for extension " + candidate.getId(), e); |
| 02:32:41 | <LeeBreisacher1> djazayeri: yeah.. |
| 02:32:43 | <djazayeri> LeeBreisacher1: so presumably the id of the extension point whose test failed is probably in the log too |
| 02:33:08 | <LeeBreisacher1> djazayeri: ah. looking.. |
| 02:33:17 | <djazayeri> LeeBreisacher1: I suspect this error is being logged for patients with no active visit also, and we should clean up the "require" expression on the extension point so this doesn't happen |
| 02:33:51 | <LeeBreisacher1> djazayeri: Failed to evaluate 'require' check for extension referenceapplication.realTime.vitals |
| 02:35:03 | <LeeBreisacher1> djazayeri: sigh. sorry. yes, it DOES happen for just-registered patients! |
| 02:35:54 | <djazayeri> LeeBreisacher1: see, it's NOT your fault |
| 02:36:16 | <LeeBreisacher1> djazayeri: yeah. note that after "confirm" on register patient, it goes directly to the dashboard |
| 02:37:00 | <LeeBreisacher1> djazayeri: so, I'm going to continue filling in the visit details. good way for me to learn the basic data structures |
| 02:37:41 | <LeeBreisacher1> djazayeri: and joda-time is quite handy for doing date arithmetic. an amazing package. |
| 02:37:56 | <djazayeri> LeeBreisacher1: and I'll go back to pretending I wasn't secretly trying to get you to look at the real API code |
| 02:38:02 | <djazayeri> yes, joda-time is awesome |
| 02:38:46 | <LeeBreisacher1> djazayeri: dinner-time here.. (well, as soon as we figure out what to make/buy..) |
| 02:38:57 | <djazayeri> LeeBreisacher1: enjoy |
| 02:54:53 | *** dan has joined #openmrs |
| 03:14:24 | *** dan has quit IRC |
| 03:45:13 | *** jkeiper has quit IRC |
| 03:45:42 | *** akwatuha__ has quit IRC |
| 03:45:58 | *** DraggonZ has quit IRC |
| 03:46:16 | *** lstanisic has quit IRC |
| 03:46:46 | *** nribeka has quit IRC |
| 03:47:07 | *** downey has quit IRC |
| 03:47:49 | *** h3llborn has quit IRC |
| 05:42:52 | *** harsz89 has quit IRC |
| 06:09:30 | *** DraggonZ has joined #openmrs |
| 06:09:30 | *** ChanServ sets mode: +v DraggonZ |
| 06:10:08 | *** akwatuha__ has joined #openmrs |
| 06:16:50 | *** downey has joined #openmrs |
| 06:16:50 | *** ChanServ sets mode: +o downey |
| 06:16:50 | *** OpenMRSBot sets mode: +o downey |
| 06:17:32 | *** jkeiper has joined #openmrs |
| 06:17:32 | *** ChanServ sets mode: +v jkeiper |
| 06:19:40 | *** lstanisic has joined #openmrs |
| 06:20:21 | *** h3llborn has joined #openmrs |
| 06:20:21 | *** ChanServ sets mode: +v h3llborn |
| 06:20:24 | *** nribeka has joined #openmrs |
| 06:20:24 | *** ChanServ sets mode: +v nribeka |
| 08:12:58 | *** harsz89 has joined #openmrs |
| 08:12:58 | *** ChanServ sets mode: +v harsz89 |
| 09:04:22 | <OpenMRSBot> Recent updates in the world of openmrsci: REFAPP-OMODDISTRO-1281 has FAILED : Updated by Lee Breisacher <https://ci-stg.openmrs.org/browse/REFAPP-OMODDISTRO-1281> || CA-CA-286 has FAILED (4 tests failed) : Dependant of EMRAPI-EMRAPI-148 <https://ci-stg.openmrs.org/browse/CA-CA-286> || RDD-RDD-38 has FAILED (1 tests failed) : Dependant of EMRAPI-EMRAPI-146 <https://ci-stg.openmrs.org/browse/RDD-RDD-38> || RDD-RDD-36 has FAILED (2 tests failed) : Updated by Wyclif Luyima <https://ci-stg.openmrs.org/browse/RDD-RDD-36> || REFAPP-STAND-12 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-12> || REFAPP-STAND-11 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-11> || SON-REGISCORE-7 has FAILED : Manual build by RafaÅ Korytkowski <https://ci-stg.openmrs.org/browse/SON-REGISCORE-7> || SON-OPENMRSCOREMASTER-3 has FAILED : Manual build by RafaÅ Korytkowski <https://ci-stg.openmrs.org/browse/SON-OPENMRSCOREMASTER-3> || SON-UILIBRARY-3 has FAILED : Manual build by RafaÅ Korytkowski <https://ci-stg.openmrs.org/browse/SON-UILIBRARY-3> || SON-HTMLFORM19EXT-3 has FAILED : Manual build by RafaÅ Korytkowski <https://ci-stg.openmrs.org/browse/SON-HTMLFORM19EXT-3> || REFAPP-STAND-8 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-8> || SON-REPORTINGUI-2 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-REPORTINGUI-2> || SON-RESTWEBSERV-2 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-RESTWEBSERV-2> || SON-IDGEN-2 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-IDGEN-2> || SON-METAMAPPING-2 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-METAMAPPING-2> || SON-OPENMRSCOREMASTER-2 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-OPENMRSCOREMASTER-2> || SON-HTMLFORMENTRY-2 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-HTMLFORMENTRY-2> || SON-HTMLFORM19EXT-2 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-HTMLFORM19EXT-2> || SON-APPUI-3 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-APPUI-3> || SON-REGISCORE-6 has FAILED : Scheduled build <https://ci-stg.openmrs.org/browse/SON-REGISCORE-6> || SON-REPORTING-1 has FAILED : Manual build by Ozge Catalbas <https://ci-stg.openmrs.org/browse/SON-REPORTING-1> || SON-METASHARING-1 has FAILED : Manual build by Ozge Catalbas <https://ci-stg.openmrs.org/browse/SON-METASHARING-1> || SON-LOGIC-1 has FAILED : Manual build by Ozge Catalbas <https://ci-stg.openmrs.org/browse/SON-LOGIC-1> || REFAPP-STAND-7 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-7> || REFAPP-STAND-6 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-6> || REFAPP-STAND-5 has FAILED : Rebuilt by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-5> || REFAPP-STAND-4 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-4> || REFAPP-STAND-3 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-3> || REFAPP-STAND-2 has FAILED : Manual build by Daniel Kayiwa <https://ci-stg.openmrs.org/browse/REFAPP-STAND-2> || CA-CA-277 has FAILED (2 tests failed) : Updated by djazayeri <https://ci-stg.openmrs.org/browse/CA-CA-277> |
| 11:45:48 | *** djazayeri has quit IRC |
| 12:50:52 | *** harsz89 has quit IRC |
| 13:11:06 | *** LeeBreisacher1 has left #openmrs |
| 13:28:12 | *** LeeBreisacher1 has joined #openmrs |
| 13:41:18 | *** suranga__ has quit IRC |
| 13:41:35 | *** suranga__ has joined #openmrs |
| 13:43:49 | *** harshadura has joined #openmrs |
| 13:43:49 | *** ChanServ sets mode: +v harshadura |
| 13:50:45 | *** harshadura has quit IRC |
| 14:11:17 | *** sgithens has joined #openmrs |
| 14:20:02 | *** sgithens has quit IRC |
| 14:32:59 | *** sgithens has joined #openmrs |
| 15:15:35 | *** harshadura has joined #openmrs |
| 15:15:35 | *** ChanServ sets mode: +v harshadura |
| 16:22:35 | *** wyclif has joined #openmrs |
| 16:53:48 | *** harshadura has quit IRC |
| 17:17:24 | *** harsz89 has joined #openmrs |
| 17:17:24 | *** ChanServ sets mode: +v harsz89 |
| 17:31:10 | *** sgithens has quit IRC |
| 18:21:01 | *** djazayeri has joined #openmrs |
| 18:21:01 | *** ChanServ sets mode: +o djazayeri |
| 18:48:53 | <LeeBreisacher1> djazayeri: hi. what's the data structure for a VisitNote? |
| 18:53:15 | *** dkayiwa has joined #openmrs |
| 19:04:14 | <LeeBreisacher1> djazayeri: I see..looks like just a bunch of Obs with specific concepts. |
| 19:04:29 | *** rday has joined #openmrs |
| 19:04:34 | <LeeBreisacher1> djazayeri: I guess the question is whether there's a class that encapsulates it? |
| 19:20:45 | <djazayeri> LeeBreisacher1: see https://github.com/openmrs/openmrs-module-referenceapplication/blob/master/omod/src/main/webapp/resources/htmlforms/simpleVisitNote.xml |
| 19:20:47 | <OpenMRSBot> <http://ln-s.net/:4R8> (at github.com) |
| 19:21:30 | <djazayeri> LeeBreisacher1: basically it's a single observation for the free text comments, which has concept CIEL:159395. (Though this concept is _wrong_ and will be fixed in early october, so put a TODO comment about that) |
| 19:21:42 | <djazayeri> LeeBreisacher1: and there are "encounter diagnoses" |
| 19:22:21 | <djazayeri> LeeBreisacher1: which you can create by building Diagnosis objects, and using emrApiProperties.getDiagnosisMetadata()'s method to turn into an obs group |
| 19:22:55 | <LeeBreisacher1> djazayeri: ok. thanks. |
| 19:24:50 | <djazayeri> going offline for a while |
| 20:12:48 | *** rday has quit IRC |
| 20:26:07 | *** djazayeri has quit IRC |
| 20:27:20 | *** rday has joined #openmrs |
| 21:15:08 | *** dkayiwa has quit IRC |
| 21:34:09 | *** djazayeri has joined #openmrs |
| 21:34:09 | *** ChanServ sets mode: +o djazayeri |
| 21:50:00 | *** wyclif has quit IRC |
| 21:52:43 | *** wyclif has joined #openmrs |
| 21:54:58 | *** wyclif has quit IRC |
| 23:25:53 | <LeeBreisacher1> djazayeri: I just committed/pushed some more WIP. it's basically all there except for the Visit Notes. |
| 23:26:16 | <LeeBreisacher1> djazayeri: going out for the evening. but I'll be back at it tomorrow afternoon. |
| 23:26:40 | <djazayeri> LeeBreisacher1: awesome. I'm going to flying to Boston tomorrow, so mainly offline. |
| 23:26:49 | <LeeBreisacher1> djazayeri: one question: I didn't realize there was an EmrApi module. should I be looking at that? |
| 23:27:13 | <LeeBreisacher1> djazayeri: if you have time to review what I just posted, that would be nice. |
| 23:27:44 | <djazayeri> LeeBreisacher1: I'll try to look at your commit. Not sure if I'll have time today though. |
| 23:29:40 | <LeeBreisacher1> djazayeri: one question: I didn't realize there was an EmrApi module. should I be looking at that? |
| 23:29:53 | <djazayeri> LeeBreisacher1: for what purpose? |
| 23:30:18 | <djazayeri> LeeBreisacher1: The module exists and it has some useful APIs, but not sure if any of them are relevant for what you're doing. |
| 23:30:24 | <LeeBreisacher1> djazayeri: I don't know. just thought it might have higher-level easier-to-use APIs for constructing objects |
| 23:30:58 | <djazayeri> LeeBreisacher1: I'll try to comment when looking at your commit if there's anything I think is easier in emrapi |
| 23:31:10 | <LeeBreisacher1> djazayeri: ok then. I'll just keep on going. |
| 23:46:54 | *** djazayeri has quit IRC |