| 00:10:03 | *** burke has quit IRC |
| 00:31:24 | *** lh has quit IRC |
| 00:48:48 | *** djazayeri has quit IRC |
| 01:31:53 | *** gbastien has quit IRC |
| 02:33:06 | *** burke has joined #openmrs |
| 02:33:06 | *** ChanServ sets mode: +o burke |
| 02:49:42 | *** upul` has joined #openmrs |
| 02:49:55 | *** ChanServ sets mode: +v upul` |
| 02:50:11 | *** deadpool has joined #openmrs |
| 03:03:10 | *** muthah_ has joined #openmrs |
| 03:03:11 | *** muthah has quit IRC |
| 03:03:12 | *** muthah_ is now known as muthah |
| 03:08:16 | *** muthah has quit IRC |
| 03:09:10 | *** muthah has joined #openmrs |
| 03:11:35 | *** muthah has quit IRC |
| 03:12:16 | *** muthah has joined #openmrs |
| 03:15:00 | *** muthah_ has joined #openmrs |
| 03:15:01 | *** muthah has quit IRC |
| 03:15:02 | *** muthah_ is now known as muthah |
| 03:16:19 | <deadpool> does anyone know if you can change the frequency options in regimens from what they are standard? |
| 03:17:18 | *** surangak has joined #openmrs |
| 03:17:45 | *** muthah has quit IRC |
| 03:19:01 | *** muthah has joined #openmrs |
| 03:23:11 | *** muthah has quit IRC |
| 03:26:28 | *** muthah has joined #openmrs |
| 03:26:50 | <surangak> meeting at nine |
| 03:27:07 | <surangak> oh, sorry, please ignore, wrong window :-( |
| 03:30:55 | *** deadpool has quit IRC |
| 03:31:34 | *** deadpool has joined #openmrs |
| 03:34:38 | *** burke has quit IRC |
| 04:13:26 | *** djazayeri has joined #openmrs |
| 04:13:26 | *** ChanServ sets mode: +o djazayeri |
| 04:40:40 | <surangak> wow djazayeri still here ? |
| 04:41:11 | <djazayeri> I'm here but working on something else on another workspace |
| 04:41:36 | <surangak> :-) |
| 04:55:12 | *** muthah has quit IRC |
| 06:00:23 | *** deadpool has quit IRC |
| 06:00:30 | *** dkayiwa has joined #openmrs |
| 06:01:10 | *** deadpool has joined #openmrs |
| 06:22:59 | *** rafa_ has joined #openmrs |
| 06:22:59 | *** ChanServ sets mode: +v rafa_ |
| 06:35:21 | *** dkayiwa_ has joined #openmrs |
| 06:36:45 | *** dkayiwa has quit IRC |
| 06:36:46 | *** dkayiwa_ is now known as dkayiwa |
| 06:43:13 | *** robbyoconnor has quit IRC |
| 06:43:36 | *** robbyoconnor has joined #openmrs |
| 06:43:36 | *** ChanServ sets mode: +v robbyoconnor |
| 06:49:48 | <surangak> dkayiwa, helooo |
| 06:49:55 | <dkayiwa> hey surangak |
| 06:50:04 | <surangak> dkayiwa, can i ask small question :) |
| 06:50:19 | <dkayiwa> surangak: even a big one :) |
| 06:50:25 | <surangak> dkayiwa, :) |
| 06:50:31 | <surangak> i have a drop down list |
| 06:50:40 | <surangak> <select id="itemsPerPage" name="itemsPerPage" onchange="reloadPage(${firstRecordId})"> |
| 06:50:40 | <surangak> <option value="2" selected="selected">1</option> |
| 06:50:40 | <surangak> <option value="5">5</option> |
| 06:50:40 | <surangak> <option value="10">10</option> |
| 06:50:40 | <surangak> </select> |
| 06:50:52 | <surangak> i need to access the selected value in the jsp itself |
| 06:51:14 | <surangak> this ${param.itemsPerPage} should work, right ? |
| 06:51:27 | <dkayiwa> i do not think so |
| 06:51:38 | <surangak> ummm |
| 06:51:43 | <surangak> how would u do it ? |
| 06:51:44 | <dkayiwa> do you want to get it after the onchange event? |
| 06:52:03 | <surangak> since i have 10 selected already |
| 06:52:17 | <surangak> it should work with or without onchange getting called..... |
| 06:52:26 | <surangak> sorry, i mean 1 selected.. |
| 06:52:33 | <surangak> <option value="2" selected="selected">1</option> |
| 06:53:21 | <dkayiwa> do you just want get the selected value on page load? |
| 06:53:54 | <surangak> when someone clicks on a link, i want to get whatever has been selected on the list.. :) |
| 06:54:35 | <dkayiwa> ummmmmmmm |
| 06:54:57 | <surangak> could u point me to something similar maybe ? |
| 06:54:59 | <dkayiwa> i may need to see the entire jsp on like pastebin :) |
| 06:55:05 | <surangak> ohhhh |
| 06:55:06 | <surangak> sure |
| 06:57:43 | <dkayiwa> 8) |
| 06:58:51 | <surangak> dkayiwa, http://pastebin.com/QqQ3kYXq |
| 06:59:06 | <surangak> my drop down is on line 29 |
| 06:59:08 | <dkayiwa> ok |
| 06:59:33 | <surangak> the code that needs the value is on line 133... |
| 07:00:18 | <dkayiwa> and you want the link to always point to the selected value? |
| 07:00:32 | <surangak> yeps |
| 07:00:55 | <dkayiwa> i think that will require some dynamism (javascript) |
| 07:01:00 | <surangak> that is, when someone clicks on it, it much take the default selected value or the one the user just picked :-) |
| 07:01:01 | <surangak> ohh |
| 07:01:15 | <surangak> i have a javascript code snipped |
| 07:02:04 | <surangak> oh i see, when someone clicks on the link, we lead him to a jsp with the real link, right ? |
| 07:03:18 | <dkayiwa> the link will reference a javascript function which gets the currently selected value |
| 07:03:43 | <surangak> oh, rightttt |
| 07:03:46 | <surangak> i wll do it that way |
| 07:03:49 | <dkayiwa> ok |
| 07:03:54 | <surangak> thanks dkayiwa let me try it out :P |
| 07:03:59 | <dkayiwa> 8) |
| 07:10:00 | *** bryq has joined #openmrs |
| 07:10:00 | *** ChanServ sets mode: +v bryq |
| 07:14:43 | *** muthah has joined #openmrs |
| 07:16:21 | <deadpool> djazayeri: can you use openmrs require priveledge tag to see certain links within a page and if so how i was looking on the website and didn't see how to do it |
| 07:18:02 | <dkayiwa> deadpool: looks like the more appropriate tag for that is as in this example |
| 07:18:13 | <dkayiwa> <openmrs:hasPrivilegeprivilege="PrivilegeName"> |
| 07:18:50 | <dkayiwa> deadpool: whatever is in the body of that tag will be displayed only if the logged on user has the privilege |
| 07:30:31 | *** deadpool has quit IRC |
| 07:31:08 | *** deadpool has joined #openmrs |
| 07:39:00 | <dkayiwa> surangak: you seem to be sprinting but i do not see your name here https://wiki.openmrs.org/display/RES/2011-09-05+Development+Sprint :) |
| 07:39:07 | <OpenMRSBot> <http://ln-s.net/9$Nx> (at wiki.openmrs.org) |
| 07:39:15 | <surangak> dkayiwa, oh, sorry |
| 07:39:23 | <dkayiwa> d:) |
| 07:39:23 | <surangak> let me do that... |
| 07:50:11 | <dkayiwa> hi rafa_ |
| 07:50:18 | * rafa_ rafa |
| 07:50:22 | <rafa_> hi dkayiwa |
| 07:50:36 | *** rafa_ is now known as rafa |
| 07:50:53 | <dkayiwa> rafa_: have you tried to sync and got this status on the sync item: AWAITING CONFIRMATION |
| 07:51:02 | <dkayiwa> that is under history of changes |
| 07:52:01 | <rafa> dkayiwa: No, I haven't seen that. |
| 07:52:04 | <dkayiwa> ok |
| 07:52:10 | <rafa> dkayiwa: Is it blocking furhter synchronization? |
| 07:52:26 | <dkayiwa> changes are not on the parent |
| 07:52:36 | <dkayiwa> rafa: and looks like because of that status |
| 07:53:11 | <rafa> dkayiwa: you can try entering that item and reseting the status |
| 07:53:20 | <dkayiwa> ok |
| 07:53:32 | <dkayiwa> rafa: resetting status in database? |
| 07:53:47 | <rafa> dkayiwa: you can do it easily from the history of changes page |
| 07:53:52 | <dkayiwa> ok |
| 07:53:57 | <rafa> dkayiwa: just click on the item and you'll see its details |
| 07:54:02 | <dkayiwa> ok |
| 07:54:04 | <dkayiwa> thanks |
| 07:54:07 | <rafa> dkayiwa: and there's a linke reset As NEW |
| 07:54:11 | <dkayiwa> ok |
| 07:56:57 | *** deadpool_ has joined #openmrs |
| 07:59:16 | *** deadpool has quit IRC |
| 07:59:44 | *** deadpool has joined #openmrs |
| 08:01:23 | *** deadpool_ has quit IRC |
| 08:02:20 | <dkayiwa> rafa: thanks for the tip. there were some failing records which prevented the whole operation. so i was able to sync after configuring them to the IGNORE status |
| 08:02:44 | <rafa> dkayiwa: cool |
| 08:34:58 | *** muthah has quit IRC |
| 08:35:21 | *** muthah has joined #openmrs |
| 08:37:49 | <rafa> !ticket SYNC-190 |
| 08:37:50 | <OpenMRSBot> rafa: [#SYNC-190] there should be UI functionality to reset state and retry_count on child servers when max retry count is reached - OpenMRS JIRA - https://tickets.openmrs.org/browse/SYNC-190 |
| 08:39:54 | *** deadpool has quit IRC |
| 08:40:47 | *** deadpool has joined #openmrs |
| 08:58:59 | *** dkayiwa has quit IRC |
| 09:00:33 | <deadpool> djazayeri: can a referencedata method return a modelandview object? |
| 09:03:16 | <rafa> deadpool: it's a middle of the night for djazayeri ;) |
| 09:03:33 | <rafa> deadpool: you can try again in 5 hours |
| 09:03:44 | <deadpool> rafa: thanks for the heads up |
| 09:04:09 | <deadpool> rafa: can referencedata method return a model and view object do you know? |
| 09:04:43 | <rafa> deadpool: I'm not sure what referencedata you've got in mind... |
| 09:04:55 | <deadpool> for a form |
| 09:05:44 | <rafa> deadpool: Can you describe what is it that you're trying to do? |
| 09:05:55 | <deadpool> what i am trying to do is i have a link which i want the user to click and some action behind the screen will happen and reload the place where the link was and i was thinking the referencedata method could do it because i don't want to create another webpage to do an onsubmit |
| 09:07:21 | <rafa> deadpool: so you want to use simple ajax query? |
| 09:09:12 | <deadpool> uh sure but i don't know how to do that |
| 09:09:38 | <deadpool> well what i want to do is change a database table from true to false and i thought just clicking a link i could do that |
| 09:10:35 | <rafa> deadpool: https://source.openmrs.org/browse/Modules/metadatasharing/branches/publish-subscribe/web/src/org/openmrs/module/metadatasharing/web/controller/SubscriptionController.java?hb=true |
| 09:10:41 | <OpenMRSBot> <http://ln-s.net/9$Q2> (at source.openmrs.org) |
| 09:10:48 | <rafa> deadpool: see for example the downloadPackageAjax method |
| 09:12:28 | <rafa> deadpool: the finishDownaload method shows how to do it without writing anything to response |
| 09:12:39 | <rafa> deadpool: it might be enough for your usecase |
| 09:15:06 | <deadpool> rafa: your using annotations i am not still using the moduleapplicationcontext.xml |
| 09:16:01 | <rafa> deadpool: it's easy to turn annotations on |
| 09:16:14 | <rafa> deadpool: just add in moduleApplicationContext.xml one line |
| 09:16:16 | <rafa> <context:component-scanbase-package="@MODULE_PACKAGE@"/> |
| 09:16:39 | <rafa> deadpool: and then you can use annotations |
| 09:17:15 | <rafa> deadpool: you might need to include context: schemaLocation as well |
| 09:18:34 | <rafa> deadpool: best see https://source.openmrs.org/browse/~br=trunk/Modules/metadatasharing/trunk/metadata/moduleApplicationContext.xml?hb=true |
| 09:18:38 | <OpenMRSBot> <http://ln-s.net/9$QE> (at source.openmrs.org) |
| 09:19:20 | <rafa> deadpool: see first ~12 lines |
| 09:19:23 | <deadpool> rafa thanks |
| 09:19:44 | <rafa> deadpool: you're welcome |
| 09:27:15 | *** bwolfe has joined #openmrs |
| 09:27:15 | *** ChanServ sets mode: +o bwolfe |
| 09:27:27 | *** bwolfe has quit IRC |
| 09:27:35 | *** bwolfe has joined #openmrs |
| 09:27:35 | *** ChanServ sets mode: +o bwolfe |
| 10:12:28 | *** dkayiwa has joined #openmrs |
| 10:18:48 | *** deadpool has quit IRC |
| 10:19:35 | *** deadpool has joined #openmrs |
| 10:20:28 | <dkayiwa> hi bwolfe |
| 10:20:37 | <bwolfe> hi dkayiwa |
| 10:22:08 | <dkayiwa> bwolfe: apart from Upgrade Scripts and Help/FAQ, the rest of the sync admin links require the Manage Synchronization. Should i change them to require the View Synchronization Status privilege such that the user can see whats there? SYNC-167 |
| 10:22:47 | <dkayiwa> bwolfe: to satisfy this: 2) Sync Assistant (one who can see sync status, etc, but not start the sync process) |
| 10:23:16 | <bwolfe> yes, the pages should be changed, but then show/hide links/content in the page depending on whether they have Manage Sync priv or not |
| 10:23:29 | <dkayiwa> ok |
| 10:24:36 | <dkayiwa> bwolfe: lasts, will i need to create the Sync Assistant privilege? I do not see a need for that since it will satisfied by the View Synchronization Status privilege |
| 10:25:32 | <bwolfe> no |
| 10:25:39 | <bwolfe> Sync Assistant would be a role anyway |
| 10:25:48 | <dkayiwa> ok |
| 10:27:55 | <dkayiwa> bwolfe: one other thing i have discovered is that the Sync Assistant role will need three privileges: View Synchronization Status, Manage Scheduler, and View Administration Functions privileges. Am i on the right track? |
| 10:28:30 | <bwolfe> admin functions, ok |
| 10:28:33 | <bwolfe> but manage schedule? |
| 10:28:36 | <bwolfe> *scheduler |
| 10:29:30 | <dkayiwa> bwolfe: the sync Overview and Configuration links have their controllers call Context.getSchedulerService().getRegisteredTasks() |
| 10:29:56 | <bwolfe> ok, so use proxy privilege so that its not needed |
| 10:29:56 | <dkayiwa> bwolfe: so it is that which requires the Manage Scheduler privilege |
| 10:30:04 | <dkayiwa> ok |
| 10:30:28 | <dkayiwa> bwolfe: should i also proxy for the View Administration Functions ? |
| 10:31:51 | <bwolfe> no, they'll need that to just get to the pages |
| 10:31:58 | <dkayiwa> ok |
| 10:32:01 | <bwolfe> is that being required /in/ the pages ? |
| 10:32:08 | <dkayiwa> no |
| 10:32:19 | <dkayiwa> just a way of getting to the admin links for sync |
| 10:32:27 | <bwolfe> right |
| 10:39:09 | *** deadpool has quit IRC |
| 10:39:57 | *** deadpool has joined #openmrs |
| 10:45:41 | *** rafa has quit IRC |
| 10:46:24 | *** rafa has joined #openmrs |
| 10:46:24 | *** ChanServ sets mode: +v rafa |
| 10:52:40 | <surangak> bwolfe, hi, i have a question :-) |
| 10:52:57 | <bwolfe> ok, fire away |
| 10:53:05 | <surangak> im working on pagination |
| 10:53:16 | <surangak> so assume im looking at the records 10 at a time |
| 10:53:24 | <surangak> so page 1 will display records 1-10 |
| 10:53:33 | <surangak> page 2 will have 11-20 etc. |
| 10:53:43 | <surangak> assume i came to page 2 ( records 11-20) |
| 10:53:54 | <surangak> and decided i wanted to see 50 records per page |
| 10:53:55 | *** deadpool has quit IRC |
| 10:54:06 | <surangak> so if i selected 50 records from the drop down |
| 10:54:20 | <surangak> dill it show me records 11 to 60 |
| 10:54:24 | <surangak> or 1 to 50 |
| 10:54:32 | <surangak> (remember that im now on the second page) |
| 10:54:45 | <bwolfe> probably 11 to 60 |
| 10:55:01 | <surangak> ok.. will do |
| 10:55:16 | <surangak> plus ill need to introduce a new jquery library to get url params :-) |
| 10:55:34 | <surangak> i mean a scripe file. is that ok ? |
| 10:56:34 | <bwolfe> are you doing this all with jquery? |
| 10:57:04 | <surangak> no, i will need for this part, to get the url param for drop down :-( |
| 10:57:10 | <surangak> ill need it only for this |
| 10:57:20 | <surangak> should i use javascript instead ? |
| 11:01:22 | <surangak> Ben i'll be going offline now, but i'll check the log later, so please respond here when u r free :-) |
| 11:01:51 | <bwolfe> ok, plain js would be about 2 lines |
| 11:01:57 | <bwolfe> I don't see a need for a whole library :-) |
| 11:02:10 | <bwolfe> simple solutions are better |
| 11:02:22 | <bwolfe> the bigger the changes the longer it takes to review and the more likely something gets broken |
| 11:06:03 | *** surangak has quit IRC |
| 11:06:06 | *** deadpool has joined #openmrs |
| 11:15:06 | <upul`> linux is 20 |
| 11:18:42 | <bwolfe> and I am not |
| 11:30:14 | *** upul` has quit IRC |
| 11:30:44 | <dkayiwa> bwolfe: should i give the Sync Assistant role the View Synchronization Records privilege? |
| 11:31:08 | <dkayiwa> bwolfe: i had given him only the View Synchronization Status privilege |
| 11:31:50 | <bwolfe> dkayiwa, you don't have to create the role. users can do that on their own if they want to |
| 11:31:59 | <dkayiwa> bwolfe: oh i see |
| 11:32:01 | <dkayiwa> thanks |
| 11:47:51 | *** deadpool has quit IRC |
| 11:54:16 | *** deadpool has joined #openmrs |
| 12:21:20 | *** yanokwa has joined #openmrs |
| 12:21:20 | *** ChanServ sets mode: +v yanokwa |
| 12:27:39 | *** wyclif has quit IRC |
| 12:30:26 | *** burke has joined #openmrs |
| 12:30:26 | *** ChanServ sets mode: +o burke |
| 12:33:03 | *** yanokwa has quit IRC |
| 12:35:48 | *** chughgaurav has joined #openmrs |
| 12:49:21 | *** chopin has joined #openmrs |
| 12:49:40 | <chopin> o/ |
| 12:53:54 | <burke> When are the daily scrum meetings? Looking at the sprint page (https://wiki.openmrs.org/x/oYN1AQ), it doesn't say. |
| 12:54:06 | *** jriley has joined #openmrs |
| 12:54:40 | <bwolfe> burke: 10am for you |
| 12:56:46 | <burke> tough timing for the AMPATH team (in the middle of their transfer from work to home) |
| 12:57:53 | <bwolfe> burke, 5-530pm is not that bad |
| 12:59:53 | *** chopin has quit IRC |
| 13:00:54 | *** deadpool has quit IRC |
| 13:02:02 | *** chopin has joined #openmrs |
| 13:02:13 | *** deadpool has joined #openmrs |
| 13:07:42 | *** burke has quit IRC |
| 13:18:33 | *** wyclif has joined #openmrs |
| 13:18:39 | *** robbyoconnor has quit IRC |
| 13:26:22 | *** deadpool has quit IRC |
| 13:27:05 | <chughgaurav> I cannot see the presenter's screen on connnect |
| 13:27:06 | *** deadpool has joined #openmrs |
| 13:27:12 | *** jkeiper has joined #openmrs |
| 13:27:15 | *** goutham has joined #openmrs |
| 13:27:23 | *** ChanServ sets mode: +v jkeiper |
| 13:27:39 | <dkayiwa> chughgaurav: did you chose the correct room? |
| 13:29:24 | <chughgaurav> dkayiwa:I don't know about the room , how do I choose the room ? I can see 3 users in the room , including Burke |
| 13:30:00 | <jkeiper> sorry guys, but i can't claim a sync ticket yet ... too many fires in AMPATH today :) |
| 13:30:06 | <jkeiper> s/:)/:( |
| 13:30:14 | <dkayiwa> chughgaurav: did you got through this url? https://wiki.openmrs.org/display/RES/Connect+Meeting+Rooms |
| 13:30:21 | <OpenMRSBot> <http://ln-s.net/9$Vu> (at wiki.openmrs.org) |
| 13:30:36 | <dkayiwa> chughgaurav: and then choose the one for OpenMRS University ? |
| 13:30:40 | *** yanokwa has joined #openmrs |
| 13:30:40 | *** ChanServ sets mode: +v yanokwa |
| 13:31:24 | <chughgaurav> yes , I did the same ,but I couldn't see . |
| 13:31:40 | <dkayiwa> chughgaurav: may be try doing it again |
| 13:31:44 | <jkeiper> i take that back ... |
| 13:31:51 | *** yanokwa has quit IRC |
| 13:32:00 | <chughgaurav> dkayiwa: I opened a new tab , & it's working now . Thanks |
| 13:32:02 | *** deadpool has quit IRC |
| 13:32:12 | <dkayiwa> ok good |
| 13:32:13 | *** downeym has joined #openmrs |
| 13:32:13 | *** ChanServ sets mode: +o downeym |
| 13:32:13 | *** OpenMRSBot sets mode: +o downeym |
| 13:38:12 | *** goutham has quit IRC |
| 13:40:38 | *** burke has joined #openmrs |
| 13:40:38 | *** ChanServ sets mode: +o burke |
| 14:00:39 | *** gbastien has joined #openmrs |
| 14:06:47 | <djazayeri> downeym: once we've recorded a connect meeting, how do we find its url? |
| 14:07:10 | *** chughgaurav has quit IRC |
| 14:07:42 | <bwolfe> djazayeri, did you stop the recording already? |
| 14:08:14 | <downeym> djazayeri: you should be able to log in to the main connect site and get its recording under the meeting's page |
| 14:08:29 | *** burke has quit IRC |
| 14:08:31 | <downeym> djazayeri: you'll need to "make public" first |
| 14:08:39 | <downeym> " OpenMRS University_Sept 7th " |
| 14:08:55 | <djazayeri> what's the main connect site? |
| 14:09:03 | <downeym> http://breeze.iu.edu/ |
| 14:10:01 | <djazayeri> okay, I don't have a password for that |
| 14:10:10 | <djazayeri> (I forgot it since last week, and I haven't received the reset password email yet) |
| 14:10:28 | <downeym> hrm, did you log in to the meeting? if so it's the same |
| 14:10:42 | <bwolfe> he was a guest and I made him a host |
| 14:10:53 | <djazayeri> ah, found it |
| 14:10:54 | <downeym> arh |
| 14:11:06 | <djazayeri> I had never reset the original one they emailed me |
| 14:12:28 | <djazayeri> downeym: what folder are the meetings under? |
| 14:12:43 | <downeym> OpenMRS |
| 14:12:53 | <downeym> User Meetings > OpenMRS |
| 14:12:58 | <downeym> to be more precise :) |
| 14:15:12 | <bwolfe> djazayeri, wyclif, rafa, dkayiwa, chopin: scrum time ? |
| 14:15:19 | <djazayeri> downeym: got it |
| 14:15:23 | <djazayeri> bwolfe: sure |
| 14:15:24 | <rafa> bwolfe: hi |
| 14:15:39 | <wyclif> hi |
| 14:16:27 | <dkayiwa> hi |
| 14:16:43 | <bwolfe> ok, any volunteers to go first? who's ready? |
| 14:17:31 | <rafa> I'm ready :) |
| 14:18:13 | <djazayeri> okay, go then |
| 14:18:22 | <rafa> *** Rafal *** |
| 14:18:22 | <rafa> Today: |
| 14:18:22 | <rafa> * Improved docs for the MDS |
| 14:18:22 | <rafa> * Corrected SYNC-30: Add Jump to First Error link on Sync History page |
| 14:18:22 | <rafa> https://tickets.openmrs.org/browse/SYNC-30 |
| 14:18:22 | <rafa> * Is about to commit SYNC-190: there should be UI functionality to reset state and retry_count on child servers when max retry count is reached |
| 14:18:23 | <rafa> https://tickets.openmrs.org/browse/SYNC-190 |
| 14:18:23 | <rafa> Tomorrow: |
| 14:18:24 | <rafa> * SYNC-191: there should be an indication of last ingest success/failure on parent server for each sync_server |
| 14:18:24 | <rafa> https://tickets.openmrs.org/browse/SYNC-191 |
| 14:18:25 | <rafa> No blockers. |
| 14:18:47 | <bwolfe> ok |
| 14:19:07 | <bwolfe> dkayiwa? wyclif? chopin? djazayeri? who's ready now? |
| 14:20:09 | <djazayeri> I'll og |
| 14:20:13 | <djazayeri> og -> go |
| 14:20:17 | <djazayeri> Tuesday |
| 14:20:17 | <djazayeri> * Leftover code reviews from last week's sprint (all except Wyclif's mammoth TRUNK-412) |
| 14:20:17 | <djazayeri> * Reporting design call with Mike (longer-than-intended) |
| 14:20:17 | <djazayeri> * Reviewed and applied LOGIC-92 for Tammy |
| 14:20:17 | <djazayeri> * Try again to record last week's OpenMRS University screencast -> FAIL |
| 14:20:18 | <djazayeri> * TW Code Jam |
| 14:20:19 | <djazayeri> Wednesday |
| 14:20:19 | <djazayeri> * University call |
| 14:20:20 | <djazayeri> * Design call |
| 14:20:20 | <djazayeri> * Try again to record last week's OpenMRS University screencast |
| 14:20:21 | <djazayeri> * Sprint ticket, I hope |
| 14:20:31 | <bwolfe> djazayeri, I was picturing "og" being some sort of new tango dance you learned ;-) |
| 14:20:39 | <djazayeri> Blockers: none really, but our installation process kind of sucks |
| 14:21:02 | <wyclif> djazayeri, what is the number we dial in for the openmrs university call |
| 14:21:09 | <djazayeri> 707531 |
| 14:22:26 | <bwolfe> !google openmrs+university+call |
| 14:22:26 | <OpenMRSBot> bwolfe: http://www.google.com/search?q=openmrs+university+call |
| 14:22:40 | <djazayeri> wyclif: though you don't need to be on that call unless you're invited to present |
| 14:22:45 | <djazayeri> save yourself the hour and do something else |
| 14:22:55 | <wyclif> ok |
| 14:23:03 | <dkayiwa> oh i see |
| 14:23:12 | <dkayiwa> i thought it was compulsory :) |
| 14:23:27 | <wyclif> djazayeri, i created a new review to replace the mammoth |
| 14:23:42 | <djazayeri> okay, did you see my comments on the one or two files in the mammoth? |
| 14:24:03 | <wyclif> yes |
| 14:25:10 | <wyclif> will talk one in particular after the call |
| 14:25:15 | <wyclif> sorry scrum chat |
| 14:25:24 | <wyclif> can i go? |
| 14:25:27 | <djazayeri> yes |
| 14:25:35 | <bwolfe> or og if you prefer |
| 14:26:15 | * rafa wonders what is the mammoth :) |
| 14:26:29 | <bwolfe> rafa, CR-TRUNK-503 |
| 14:26:55 | <djazayeri> og sounds like someone who hunts mammoths |
| 14:27:09 | <wyclif> yesterday: |
| 14:27:09 | <wyclif> - seeting up my dev environment for the sync module |
| 14:27:09 | <wyclif> - worked on tickets SYNC-192, SYNC-198, SYNC-41(didn't get done with this) |
| 14:27:09 | <wyclif> - created SYNC-209 |
| 14:27:09 | <wyclif> - created a new review for TRUNK-412 to replace the mammoth |
| 14:27:10 | <wyclif> today: |
| 14:27:12 | <wyclif> - continue with SYNC-41 |
| 14:27:14 | <wyclif> - pick up other sprint tickets |
| 14:27:15 | <bwolfe> ha |
| 14:27:16 | <wyclif> - respond to review comments from last sprint(low priority) |
| 14:27:44 | <bwolfe> !ticket SYNC-41 |
| 14:27:46 | <OpenMRSBot> bwolfe: [#SYNC-41] Add "Clean Up Old Sync Records" scheduled task maintenance to Maintenance page - OpenMRS JIRA - https://tickets.openmrs.org/browse/SYNC-41 |
| 14:28:09 | <wyclif> blockers: not really |
| 14:28:22 | <wyclif> just a question about SYNC-41 |
| 14:28:47 | <bwolfe> quick or long question wyclif? |
| 14:28:52 | <wyclif> it is the properties of the task that need to be managed from the added page and not start/stop the task |
| 14:28:54 | <wyclif> right? |
| 14:29:06 | <wyclif> quick |
| 14:29:24 | <bwolfe> yes, just properties |
| 14:29:27 | <wyclif> ok |
| 14:29:30 | <wyclif> thanks |
| 14:30:06 | <bwolfe> chopin, do you have an update? or dkayiwa, are you ready? |
| 14:30:17 | <dkayiwa> Finished ticket: Provide privileges for sync management tools - SYNC-167 |
| 14:30:17 | <dkayiwa> Attended OpenMRS University call |
| 14:30:18 | <dkayiwa> Now going for another ticket after working on my previous review comments from other tickets. |
| 14:30:18 | <dkayiwa> No Blockers |
| 14:31:02 | <bwolfe> dkayiwa, clean up the other tickets before claiming another one |
| 14:31:07 | <dkayiwa> ok |
| 14:31:11 | <bwolfe> dkayiwa, you have too many under your name right now ;-) |
| 14:31:18 | <dkayiwa> :) |
| 14:32:53 | <bwolfe> my update from today: |
| 14:32:54 | <bwolfe> fixed TRUNK-368 (address formats) so that new installs work again |
| 14:32:54 | <bwolfe> reviewed sync tickets for rafal, wyclif, dave |
| 14:32:54 | <bwolfe> still looking into sync failing unit tests. I fear it is a larger fix than I want to do... |
| 14:32:54 | <bwolfe> created a new sync ticket for bug ampath was running into SYNC-210 |
| 14:32:54 | <bwolfe> set up for design call |
| 14:32:56 | <bwolfe> univ call |
| 14:32:58 | <bwolfe> design call |
| 14:33:00 | <bwolfe> project management call |
| 14:33:02 | <bwolfe> tomorrow: |
| 14:33:04 | <bwolfe> dev call, sync stuff |
| 14:33:31 | <bwolfe> I need to pull either dave and/or maros into this bug hunt. it was caused by dave and previously fixed by maros |
| 14:35:03 | <bwolfe> chopin, did you work on sync yesterday? want to give an update? |
| 14:37:57 | *** downeym sets mode: +v chopin |
| 14:43:57 | <jkeiper> I did not work on sync yesterday, but I did claim SYNC-210 for today |
| 14:44:04 | <jkeiper> (as long as AMPATH fires go out quickly) |
| 14:45:59 | *** MarkG has joined #openmrs |
| 14:46:14 | <downeym> Hi MarkG and welcome to the #openmrs IRC channel. |
| 14:49:30 | <MarkG> when a Sync server attempts to ingest a SyncRecord, if some of the classes within that record are on the server's excluded list, will/should the import of the entire record fail? |
| 14:50:22 | <djazayeri> bwolfe: ^^ |
| 14:53:24 | <bwolfe> MarkG, I remember seeing this at some point last year. I THINK the answer is "yes", the entire record will faill |
| 14:53:26 | <bwolfe> *fail |
| 14:53:38 | <bwolfe> but we should change that so that only the items in the record that are excluded should fail |
| 14:56:09 | <MarkG> yeah, i think i looked into this a few weeks ago, but can't remember... |
| 14:57:11 | <MarkG> i'm running into a problem with it right now, but i'm going to look into it while I work on SYNC-195... |
| 14:57:31 | <bwolfe> !ticket SYNC-195 |
| 14:57:32 | <MarkG> there seems to be some funky stuff going on with including/excluding classes... |
| 14:57:33 | <OpenMRSBot> bwolfe: [#SYNC-195] Configure *current* server--Items NOT to Synchronize does (almost) nothing - OpenMRS JIRA - https://tickets.openmrs.org/browse/SYNC-195 |
| 14:59:28 | <MarkG> btw, did you guys see that I reopened !ticket TRUNK-1930 ? |
| 15:00:29 | <MarkG> looks like the AuditableInterceptor isn't working if Sync is installed in 1.6. |
| 15:00:38 | <MarkG> the AuditableInterceptor isn't working if Sync is installed in 1.6. |
| 15:01:27 | <bwolfe> yes, I saw it |
| 15:01:36 | <bwolfe> MarkG, but I don't care about 1.6 or 1.7 ;-) |
| 15:02:14 | <bwolfe> check the backport to make sure it included all the right files |
| 15:02:34 | <bwolfe> and all the commits for that. I know I had to do some extra stuff to the interceptor or spring to get it to register correctly with multiple |
| 15:02:43 | <bwolfe> dinnertime. bbl |
| 15:11:43 | *** sunbiz has joined #openmrs |
| 15:11:43 | *** ChanServ sets mode: +v sunbiz |
| 15:23:44 | <MarkG> any votes against removing the "Show more options" toggle on the "Configure" page and have the list of objects to send/export apperar automatically? seems important enough that we don't want people to miss it. |
| 15:36:53 | *** sunbiz has quit IRC |
| 15:43:06 | *** dkayiwa has quit IRC |
| 15:55:28 | *** downeym sets mode: +v MarkG |
| 15:56:57 | <djazayeri> MarkG: originally that was hidden because it was "advanced" |
| 15:57:26 | <djazayeri> but if it's something that needs to be configured by all sync admins, I'd agree that it shouldn't be hidden. |
| 16:24:06 | *** Suranga has joined #openmrs |
| 16:26:05 | *** muthah has quit IRC |
| 16:48:20 | *** chughgaurav has joined #openmrs |
| 17:01:17 | *** rafa has quit IRC |
| 17:13:26 | <jkeiper> bwolfe, djazayeri: have a sec to discuss FORM-126 |
| 17:13:29 | <jkeiper> ? |
| 17:18:00 | <djazayeri> !ticket form-126 |
| 17:18:02 | <OpenMRSBot> djazayeri: [#FORM-126] Properly set HL7Source on generated HL7 queue objects - OpenMRS JIRA - https://tickets.openmrs.org/browse/form-126 |
| 17:18:57 | <djazayeri> jkeiper: I think that the source of all messages coming from the formentry module should be "formentry" |
| 17:19:15 | <djazayeri> or, I suppose, "local" |
| 17:21:51 | <jkeiper> djazayeri, so ... are we saying that HL7Source refers specifically to the sending application? |
| 17:23:39 | *** dkayiwa has joined #openmrs |
| 17:24:49 | <jkeiper> here's my problem: i have to find a way to prioritize HL7s because the HL7 queue has become exceedingly slow after implementing sync module, and in the interim while I try to figure out what is causing the slow down and how to fix it, I need to prioritize particular forms. |
| 17:25:36 | <jkeiper> there are only a few properties on HL7InQueue objects, and the one that makes sense to prioritize on is HL7Source |
| 17:26:34 | <jkeiper> if I can specify the source for a given form or let FormEntry change its source based on the type of encounter the form is addressing, I can continue. |
| 17:28:14 | *** rafa has joined #openmrs |
| 17:28:14 | *** ChanServ sets mode: +v rafa |
| 17:29:09 | *** chughgaurav has quit IRC |
| 17:37:17 | *** gbastien has quit IRC |
| 17:38:11 | <jkeiper> djazayeri: right now, FormEntry sets the sending application to "FORMENTRY". If I change that to "FORMENTRY^ADULTINITIAL^L" we don't lose anything in the quality of the HL7 message, but I can have an HL7 source called "FormEntry - Adult Initial" and refer to that, no? |
| 17:39:27 | <bwolfe> the hl7 source should not be that specific |
| 17:39:36 | <bwolfe> a source is the sending application |
| 17:40:10 | <djazayeri> jkeiper: sorry, was on the phone |
| 17:40:40 | <djazayeri> How much time are you really saving by not inspecting the text of the HL7 message while prioritizing? |
| 17:40:43 | <jkeiper> so ... if I need to prioritize HL7s by the form or by encounter type, but I can't afford spending a few seconds each time looking at the hl7Data field ... how else can I prioritize them? |
| 17:40:56 | <djazayeri> Does it really take seconds to look at the hl7Data field? |
| 17:41:00 | <jkeiper> well, i'd basically be doing a like on it, right? |
| 17:41:06 | <jkeiper> with a thousand HL7s in the queue, yep |
| 17:41:17 | <djazayeri> Yeah, so prioritize a batch at a time |
| 17:41:37 | <jkeiper> erm, can you reiterate? |
| 17:42:04 | <djazayeri> (Just to clarify, the root problem is that processing each form is slow because we can't use the new Concept(5) hack anymore, right?) |
| 17:42:47 | <jkeiper> partially ... i could not speed it up by keeping a concept cache in the processor, because inflating the concepts (even just once each) still ended up taking the same amount of time |
| 17:43:04 | <jkeiper> ben says it has to do entirely with a bunch of small writes vs one large write |
| 17:43:16 | <djazayeri> Is there a getNextHl7MessageToProcess() method? Or are you planning to add one? |
| 17:43:38 | <bwolfe> jkeiper, small *reads* vs large *read* |
| 17:43:41 | <jkeiper> yes, there is one ... and i'm writing a custom getNextPrioritizedHL7Message() into my own scheduled task for this purpose |
| 17:43:46 | <jkeiper> o |
| 17:44:10 | <jkeiper> in fact, i already have the prioritized scheduled task working |
| 17:44:15 | <djazayeri> So you can AOP around that method and once every 10 calls you can do a 2-second query that fetches up to 10 adult-initial forms (or whatever) |
| 17:44:29 | <djazayeri> You actually only need conceptId->uuid, right? |
| 17:44:40 | <djazayeri> you don't need to inflate the actual concept object with its names, etc. |
| 17:44:40 | <jkeiper> yes that's true |
| 17:45:01 | <jkeiper> right, but ... keeping an ehcache should have been equivalent right? |
| 17:45:14 | <jkeiper> i mean, once they were inflated they didn't need to be re-gotten |
| 17:45:23 | <jkeiper> i made sure they weren't |
| 17:45:33 | <jkeiper> and yet it still took 10 minutes to process 1000 messages |
| 17:45:34 | <bwolfe> jkeiper, depends on the settings. |
| 17:45:38 | <djazayeri> my thought at the time (3 years ago?) had been to scan the text of the message, find all the concept ids you need, and then do a batch "select concept_id, uuid … where concept_id in …" |
| 17:45:44 | <jkeiper> entirely in memory ... |
| 17:46:01 | <bwolfe> the sync branch did something like that at one point. I'm seeing if I can find that in svn history now |
| 17:46:06 | *** MarkG_ has joined #openmrs |
| 17:46:12 | <downeym> Hi MarkG_ and welcome to the #openmrs IRC channel. |
| 17:46:37 | <djazayeri> Anyway, I believe the point is that "hl7 source" is supposed to refer to the application/installation that sent the message |
| 17:47:02 | <djazayeri> It's not intended to be used for the purpose you're proposing to use it for. And Burke will slap you with a wet noodle for suggesting it. :-) |
| 17:47:08 | <jkeiper> heh |
| 17:47:26 | <jkeiper> so ... is there anything in the HL7 spec for setting a priority level? |
| 17:47:31 | <jkeiper> i don't think there is ... |
| 17:48:08 | <djazayeri> Client-specified priority? Not that I know of. |
| 17:48:22 | <djazayeri> (But I don't know anything.) |
| 17:48:25 | <OpenMRSBot> Recent updates in the world of openmrs: On Twitter: OpenMRS: RT @_vsharma: Folks - Has anyone been able to send HL7 msgs from @OpenMRS to @oemrhq #OpenEMR #HL7. Does OpenEMR support such an interf ... <http://twitter.com/OpenMRS/statuses/111489966089056256> |
| 17:48:38 | <jkeiper> I don't see any in the ORU^R01 message :( |
| 17:48:48 | <djazayeri> However it certainly makes sense for the server to decide the priority. |
| 17:48:59 | <djazayeri> I could imagine adding a "priority" column to Hl7InQueue |
| 17:49:12 | <djazayeri> Which defaults to 0 for all messages. |
| 17:49:26 | <djazayeri> But we could introduce a Hl7MessagePrioritizer interface, that modules can implement |
| 17:49:36 | <djazayeri> or else a service method they can aop around |
| 17:49:59 | <jkeiper> AOP is so sticky ... seems like that's where most of the time is spent already slowing down HL7 processing :( |
| 17:50:02 | <djazayeri> You could do that at the time you receive the message (at which point inspecting the text is "free") |
| 17:50:12 | <jkeiper> true |
| 17:50:16 | <djazayeri> (okay, so an explicit interface) |
| 17:50:52 | <jkeiper> sorting by priority desc, id asc makes sense to me |
| 17:51:03 | <jkeiper> that way the db decides what comes next |
| 17:51:38 | <jkeiper> setting the priority, like you said, is the tricky part |
| 17:52:00 | <jkeiper> unfortunately i'll have to backport this to 1.8.x and render something pre-release for production if this is the answer |
| 17:52:13 | <djazayeri> With this solution, though, it seems like you're better off just working on speeding up the processing in the first place. |
| 17:52:14 | <djazayeri> Exactly. |
| 17:52:58 | <jkeiper> well, if priority is just a property on the HL7InQueue, i can set it in the processor that's generating the HL7InQueue items |
| 17:53:07 | <jkeiper> in there I can check against preferred encounter types, etc |
| 17:53:14 | <djazayeri> True. |
| 17:53:22 | <jkeiper> but then you want to allow admins to specify preference of one module over another, perhaps ... |
| 17:53:28 | <djazayeri> but in any case it still requires a core data model change |
| 17:53:36 | <jkeiper> so you'll need to weigh the module-provided priority against admin ... ugh |
| 17:53:59 | <jkeiper> yep, but ... mr. paul needs me to get this done ASAP (todaty) |
| 17:54:47 | <jkeiper> ok, here's what I'll do: |
| 17:54:58 | <jkeiper> 1) add an integer priority property to HL7InQueue |
| 17:55:09 | <djazayeri> Hold on—why not just speed up the processor? |
| 17:55:10 | <jkeiper> 2) add it to the other HL7 data types so we can track it |
| 17:55:11 | <djazayeri> That's not working? |
| 17:55:17 | <jkeiper> heh ... because that could take a week |
| 17:55:22 | <jkeiper> i need to put out a fire |
| 17:55:54 | <djazayeri> I mean: it seems surprising to me that making a core data model change (even pre-code-review) is the quick way of doing things. |
| 17:56:34 | <bwolfe> jkeiper, djazayeri: ha, ok, so the way the sync branch did it (meaning the code that pih used before sync was a module and while they still used infopath): fetched all concepts and kept a conceptid-->uuid map. and simply put the uuids onto the concept stubs along with the conceptid |
| 17:56:36 | <jkeiper> well, it's a simple change |
| 17:56:55 | <jkeiper> bwolfe: did that speed it up? |
| 17:56:58 | <djazayeri> bwolfe: ah, so we did exactly what I remember planning to do. :-) |
| 17:57:00 | <bwolfe> I assume so |
| 17:57:12 | <djazayeri> jkeiper: have you profiled with yourkit, btw? |
| 17:57:18 | <djazayeri> Is the slowness coming from fetching concepts? |
| 17:57:20 | <jkeiper> djazayeri: yes, several snapshots |
| 17:57:22 | <bwolfe> https://source.openmrs.org/browse/OpenMRS/branches/data_synchronization_bidirectional/src/api/org/openmrs/hl7/handler/ORUR01Handler.java?r=9710 . Look at line 157 |
| 17:57:28 | <OpenMRSBot> <http://ln-s.net/9$aH> (at source.openmrs.org) |
| 17:57:42 | <jkeiper> djazayeri: actually, i was hoping you could help me find those hotspots |
| 17:57:53 | <jkeiper> most of the time is held up in saveEncounter() |
| 17:58:00 | <jkeiper> most of that time is in LoggingAdvice |
| 17:58:10 | <djazayeri> jkeiper: are the snapshots somewhere I can look at them? |
| 17:58:10 | <jkeiper> and if you drill down, it gets into the sync before and after advice |
| 17:58:16 | * jkeiper can send them |
| 17:58:20 | <jkeiper> they're kinda large |
| 17:58:23 | <djazayeri> I have a call in 2 minutes, but I'll look at those in the background |
| 17:58:33 | <bwolfe> what before/after advice does sync have? |
| 17:58:36 | <djazayeri> get me the snapshots and I'll look |
| 17:58:36 | <jkeiper> ok, lemme get one into a file sharing url |
| 17:59:11 | <djazayeri> Usually the before/after advice is misleading—usually the time is actually in invocation.proceed(), i.e. not the advice but the method. |
| 18:03:35 | <jkeiper> djazayeri: https://slashtmp.iu.edu/files/download?FILE=jkeiper%2F38587yyAR0h |
| 18:03:42 | <OpenMRSBot> <http://ln-s.net/9$aN> (at slashtmp.iu.edu) |
| 18:05:14 | <djazayeri> anyway, I would suggest looking into the hack ben provided a link to |
| 18:06:18 | <bwolfe> jkeiper, should be a quick hack too. def faster than integrating a caching mechanism |
| 18:06:43 | <jkeiper> heh, too late on the caching mechanism |
| 18:06:56 | <jkeiper> but yeah, i'll try that |
| 18:06:58 | <jkeiper> :-/ |
| 18:08:18 | *** MarkG_ has quit IRC |
| 18:08:53 | *** MarkG_ has joined #openmrs |
| 18:09:52 | <MarkG_> anyone here actively working on the sync sprint? |
| 18:13:59 | <bwolfe> MarkG_, wyclif should be |
| 18:14:06 | <bwolfe> chopin used to be |
| 18:15:03 | <MarkG_> just wondering if the shouldDeletePatient test case is still failing for everyone, or just for me |
| 18:15:30 | *** chughgaurav has joined #openmrs |
| 18:15:42 | <bwolfe> MarkG_, http://ci.openmrs.org |
| 18:15:59 | <bwolfe> there are still 2 that are failing...and I can't get them to unfail. :-/ |
| 18:17:09 | <MarkG_> cool, didn't know we had sync on ci... |
| 18:17:21 | <bwolfe> its there for this sprint :-) |
| 18:17:32 | <MarkG_> no worries, i just wanted to make sure that it wasn't a) just an error for me, or b) something we thought we fixed but didn't |
| 18:17:33 | <bwolfe> and its been sending out emails for every commit because of those failing tests :-( |
| 18:18:10 | <MarkG_> we can mark the tests to be ignored... fwiw, only one is failing locally for me |
| 18:19:18 | <bwolfe> yeah, another fails when run in batch/maven but passes when run in junit/eclipse |
| 18:21:46 | *** gbastien has joined #openmrs |
| 18:29:11 | *** bryq1 has joined #openmrs |
| 18:29:44 | *** sunbiz has joined #openmrs |
| 18:29:56 | *** ChanServ sets mode: +v sunbiz |
| 18:30:51 | *** bryq has quit IRC |
| 18:38:07 | *** shakybonesdloc has joined #openmrs |
| 18:38:14 | <downeym> Hi shakybonesdloc and welcome to the #openmrs IRC channel. |
| 18:40:56 | <MarkG_> bwolfe, so is AMPATH using 1.8 now? |
| 18:41:36 | <bwolfe> markG_, yes |
| 18:44:44 | <sunbiz> bwolfe: 1.8.2?? |
| 18:44:47 | <sunbiz> Hi ben!! |
| 18:44:51 | <MarkG_> bwolfe, what is the convention we are using with sync... should i increment the version # with each commit (ie, the next one would be 0.975) |
| 18:45:01 | <bwolfe> hi sunny |
| 18:45:06 | <bwolfe> yes, 1.8.2 I think |
| 18:45:34 | <bwolfe> MarkG_, sure, but commits during the sprint haven't been doing that |
| 18:45:50 | *** shakybonesdloc has quit IRC |
| 18:51:30 | <sunbiz> downeym: do u know why the listserv is so slow?? |
| 18:51:48 | <downeym> sunbiz: some days seems worse than others :) |
| 18:51:51 | <sunbiz> it takes anywhere between 15min to 30min for mails to be passed on |
| 18:51:58 | <sunbiz> yes, but why?? |
| 18:52:04 | <sunbiz> shouldn't that b fixed?? |
| 18:52:15 | <downeym> sunbiz: some days I think there's a guy at IU who sits and reads every messages that goes through. |
| 18:52:27 | <sunbiz> :) I was thinking that guy was u!! |
| 18:52:33 | <downeym> ha, no |
| 18:52:41 | <downeym> in fact most of IU's stuff has been miserable the last few weeks |
| 18:52:51 | <sunbiz> downeym: did u get that email SPAM as well?? |
| 18:52:56 | <sunbiz> to change ur password!! LOL |
| 18:54:06 | <downeym> sunbiz: yeah, i have seen a whole lot of those in the spam filters lately but for some reason 1 got through |
| 18:54:22 | <sunbiz> I didnt see that email in listserv... but gmail said it came from openmrs.org |
| 18:58:05 | <sunbiz> downeym: but please find ways to fix the slow dev list |
| 18:58:16 | <sunbiz> I've responded by direct emails to ppl |
| 18:58:20 | <sunbiz> or bcc'd them... |
| 18:58:27 | <sunbiz> coz I know the listserv is slow |
| 18:59:53 | <downeym> sunbiz: the fix will be the upcoming move off from the listserv platform. meanwhile if the delay is bothering you too much or otherwise confusing, i'd recommend moving back to listserv vs. the google group and it will be less apparent. |
| 19:10:02 | *** chughgaurav has quit IRC |
| 19:10:24 | <sunbiz> moving back to the listserv?? meaning?? |
| 19:10:57 | <bwolfe> sunbiz, you can either be registerd to the google group or to the listserv right now |
| 19:11:03 | <sunbiz> I send emails to dev@o.o--- So do u mean sending email to the long openmrs-devel-l... address?? |
| 19:11:08 | <bwolfe> sunbiz, the listserv forwards to the google group |
| 19:11:14 | <sunbiz> ok |
| 19:11:27 | <sunbiz> so... we have users at two diff places |
| 19:11:32 | <sunbiz> ?? |
| 19:11:37 | <bwolfe> but that won't speed up other people's responses |
| 19:11:38 | *** lh has joined #openmrs |
| 19:11:45 | <downeym> no |
| 19:11:48 | <bwolfe> err, responses == receive times |
| 19:12:04 | <downeym> sunbiz: it appears you opted in to the google group pilot group |
| 19:12:36 | <downeym> sunbiz: on March 23 :) |
| 19:13:48 | <sunbiz> ok |
| 19:14:16 | <downeym> there are a handful of people using it directly, and they will see the discrepancy of the listserv's slowness before others (i.e., they'll see messages as soon as they're sent vs. the delay that the listserv has in processing messages) |
| 19:15:03 | <sunbiz> so when I send emails to dev@o.o.. does it go to the Google group and all the receivers at Google groups get it instantly... and those at listserv get it slow?? |
| 19:15:53 | <downeym> yes, it goes to the listserv at the same time as all other google group members. however, whether you send mail to the listserv directly, through its own web UI, or via Google Groups, there is a ~ 10 min or more delay before it's relayed out. |
| 19:16:24 | <sunbiz> but that 10min delay is because someone reads all emails :P |
| 19:16:36 | <sunbiz> just kidding :D |
| 19:16:41 | <downeym> the "black hole" of IU :) |
| 19:20:42 | <dkayiwa> hi bwolfe |
| 19:21:13 | <bwolfe> hi dkayiwa |
| 19:21:47 | <dkayiwa> bwolfe: about the SYNC-207 unit test, do you mean i create a test for the one line change i made? |
| 19:21:50 | *** downeym has quit IRC |
| 19:21:59 | *** downeym has joined #openmrs |
| 19:21:59 | *** ChanServ sets mode: +o downeym |
| 19:21:59 | *** OpenMRSBot sets mode: +o downeym |
| 19:22:00 | <bwolfe> !ticket SYNC-207 |
| 19:22:01 | <OpenMRSBot> bwolfe: [#SYNC-207] NPE when Childs UUID does not match with the one one registered for it on the Server - OpenMRS JIRA - https://tickets.openmrs.org/browse/SYNC-207 |
| 19:22:08 | <downeym> iuwifi-- |
| 19:23:26 | <bwolfe> dkayiwa, was that the one I wanted a unit test for? or the other one? |
| 19:23:46 | <dkayiwa> bwolfe: i have already create test for the other one |
| 19:23:55 | <dkayiwa> created |
| 19:24:34 | <bwolfe> dkayiwa, ah, yes, a unit test to make sure that sync can figure out the right uuid |
| 19:28:27 | *** dkayiwa has quit IRC |
| 19:29:21 | *** dkayiwa has joined #openmrs |
| 19:34:36 | *** MarkG has quit IRC |
| 19:46:58 | <sunbiz> downeym: I tried to login to http://mail.google.com/a/openmrs.org --- was taken to the crowd login page and after login got this error: SAML Error: Error decoding SAML Authentication Request: Check decoding scheme - Unexpected end of ZLIB input stream |
| 19:47:58 | <downeym> sunbiz: that's a known crowd bug from time to time. try to go to http://webmail.openmrs.org/ again and it should load OK |
| 19:48:08 | <bwolfe> crowd-- |
| 19:48:27 | <downeym> atlassian-- |
| 19:48:41 | <sunbiz> downeym, okies |
| 19:48:46 | <sunbiz> !karma crowd |
| 19:48:46 | <OpenMRSBot> sunbiz: Karma for "crowd" has been increased 0 times and decreased 1 time for a total karma of -1. |
| 19:48:59 | <sunbiz> !karma downeym |
| 19:48:59 | <OpenMRSBot> sunbiz: Karma for "downeym" has been increased 24 times and decreased 6 times for a total karma of 18. |
| 19:52:50 | <jkeiper> is there any way to turn down the LoggingAdvice log level? that's what sync is filling our log with: a ton of LoggingAdvice.invoke() INFO lines |
| 19:53:06 | <jkeiper> (around method shouldSynchronize) |
| 19:58:00 | <bwolfe> MarkG_, how do you have sync NOT filling your logs? |
| 19:58:17 | <bwolfe> jkeiper, I fear you are not able to change hte logging level because of some other module you have loaded |
| 19:58:28 | *** Suranga has quit IRC |
| 19:58:42 | <bwolfe> the GP for logging level SHOULD be able to silence the shouldSynchronize loggings |
| 19:58:44 | <jkeiper> bwolfe: i think the logging is actually in LoggingAdvice though |
| 19:59:04 | <bwolfe> yes, but loggingAdvice goes against the logging level GP |
| 19:59:17 | <MarkG_> bwolfe... there is a lot of sync logging, but it hasn't caused us any problems that i know of |
| 19:59:23 | <jkeiper> side note: every time i start/stop/upgrade a module, updateConceptIndex crap starts over again at 0 |
| 19:59:42 | <bwolfe> jkeiper, talk to wyclif about that |
| 19:59:44 | <MarkG_> actually, yeah, i don't think we get INFO messages, however |
| 20:00:04 | <bwolfe> if it doesn't ever finish it might be starting over...although I thought he made it pick up where it left off |
| 20:00:06 | <jkeiper> yeah, my log level is at WARN and i'm getting all of the LoggingAdvice INFO messages but everything else is at WARN or ERROR |
| 20:00:15 | <jkeiper> if i change it to DEBUG, I get everything |
| 20:00:28 | <jkeiper> hmm, well ... mine isn't |
| 20:00:33 | * jkeiper notes to look at it later |
| 20:02:14 | <MarkG_> actually, we may get INFO, let me check... i know I've had issues before where setting the default logging global property does not affect the logging of modules... but i've never looked into it much |
| 20:03:57 | <bwolfe> look for "shouldSynchronize" in the logs MarkG_ |
| 20:05:53 | <jkeiper> here's my rendered log4j.xml: http://pastebin.com/q1n8rmXu |
| 20:06:18 | <jkeiper> for some reason, org.openmrs.api is set to INFO |
| 20:08:55 | <MarkG_> jkeiper yes, i get them as well... i guess we just have never worried about it before |
| 20:09:28 | <jkeiper> i think it's a core setting for LoggingAdvice |
| 20:09:40 | <jkeiper> erm, maybe like bwolfe says it's in another module |
| 20:10:21 | <bwolfe> jkeiper, how did you get the rendered xml? |
| 20:10:51 | * jkeiper looked in webapps/amrs/WEB-INF/classes/log4j.xml |
| 20:11:05 | <jkeiper> it's the only log4j.xml file under webapps/amrs |
| 20:12:03 | <bwolfe> ok |
| 20:12:19 | <bwolfe> openmrs changes it in memory according to the GP setting |
| 20:14:06 | <jkeiper> ok |
| 20:18:30 | <bwolfe> jkeiper, just make a custom build of sync for amrs and change the annotation on shouldSynchronize to just @Ignore |
| 20:18:39 | <bwolfe> or whatever it is. |
| 20:18:44 | <bwolfe> its in the comment on that method |
| 20:18:46 | <bwolfe> but its 1.8 only |
| 20:22:45 | <jkeiper> bwolfe: ok |
| 20:23:00 | *** muthah has joined #openmrs |
| 20:23:43 | <OpenMRSBot> Recent updates in the world of openmrs: On Twitter: OpenMRS: RT @thingsprime: Deployed update of our Android/OpenMRS maternal health app in a clinic in Bagamoyo province today. #OpenMRS <http://twitter.com/OpenMRS/statuses/111527227228831744> |
| 20:33:58 | <jriley> downeym, you're a wiki-updating machine! |
| 20:34:24 | <downeym> :-/ |
| 20:35:51 | *** dkayiwa has quit IRC |
| 20:39:25 | <jkeiper> bwolfe, djazayeri: after adding the conceptIdToUuidMap method, I still only get 4 messages per second at best |
| 20:39:43 | <jkeiper> it's more likely to be 1 or 2 messages per second |
| 20:41:11 | <bwolfe> jkeiper, what is it without that change? |
| 20:41:57 | <jkeiper> 1 or 2 |
| 20:42:10 | <jkeiper> it seems to be ever-so-slightly faster |
| 20:42:40 | <jkeiper> i'm just grabbing the last 1000 successful HL7s from the archive and running them again |
| 20:43:02 | <jkeiper> oO i got a few seconds where 5 HL7s were processed |
| 20:43:03 | <jkeiper> that's nicer |
| 20:43:09 | <jkeiper> ooh and one at 6 |
| 20:43:24 | <jkeiper> it's faster, but paul seems to think it should be 30/sec |
| 20:46:54 | <bwolfe> what was it in 1.6 ? |
| 20:47:16 | *** dkayiwa has joined #openmrs |
| 20:47:27 | <jkeiper> looking back at historical data, we have a few instances of over 20/sec |
| 20:47:39 | <jkeiper> imma need to chart it |
| 20:47:40 | <jkeiper> :-D |
| 20:48:01 | <bwolfe> hmm |
| 20:48:07 | <bwolfe> def needs fixed then |
| 20:49:57 | <jkeiper> yeh |
| 20:49:59 | * jkeiper will be up late tonight |
| 20:50:49 | <jkeiper> see y'all later |
| 20:55:45 | *** chopin has quit IRC |
| 20:56:00 | *** jkeiper has quit IRC |
| 21:03:11 | *** bryq1 has left #openmrs |
| 21:17:40 | *** MarkG_ has quit IRC |
| 21:27:27 | *** MarkG has joined #openmrs |
| 21:27:34 | <MarkG> s there a reason the changes to the AuditableSaveHandler weren't backported to 1.7 and 1.6? I assume that is a bug--in 1.6 both the SaveHandler and the Interceptor set the date changed and changed by |
| 21:27:40 | *** MarkG has quit IRC |
| 21:27:44 | *** downeym_ has joined #openmrs |
| 21:27:44 | *** ChanServ sets mode: +o downeym_ |
| 21:28:01 | <djazayeri> MarkG: probably unintentional if it's not explicitly mentioned on the ticket. |
| 21:31:06 | *** downeym has quit IRC |
| 21:31:06 | *** downeym_ is now known as downeym |
| 21:31:32 | <wyclif> bwolfe, did jeremy resolve the conceptupdatetask issue |
| 21:31:32 | <bwolfe> can we call him "MarkyG" ? |
| 21:31:48 | <bwolfe> I think it was just a side comment, so probably not |
| 21:31:50 | <wyclif> i think it is a common pattern for all start up taks |
| 21:32:34 | <wyclif> bwolfe, there us a ticket for this |
| 21:33:15 | <bwolfe> ok, send him an email about it to see |
| 21:33:18 | <bwolfe> I'm heading ot bed |
| 21:33:20 | <bwolfe> g'night all |
| 21:33:22 | <wyclif> and i think the code was committed but there was a small review comment and the original developer working on the ticket left |
| 21:33:30 | <wyclif> goodnight |
| 21:37:38 | *** bwolfe has quit IRC |
| 21:52:36 | *** jriley has left #openmrs |
| 22:09:23 | *** wyclif has quit IRC |
| 22:40:08 | *** dkayiwa has quit IRC |
| 23:08:34 | *** rafa has quit IRC |
| 23:10:36 | *** wyclif has joined #openmrs |
| 23:12:36 | *** rafa has joined #openmrs |
| 23:12:36 | *** ChanServ sets mode: +v rafa |
| 23:14:19 | *** rafa has quit IRC |
| 23:21:56 | *** downeym has quit IRC |
| 23:28:43 | *** gbastien has quit IRC |
| 23:42:31 | *** morristic has joined #openmrs |