tmccormi wrote on Thursday, March 17, 2011:
Thanks Brady, we’re this is priority for MI2.
-Tony
tmccormi wrote on Thursday, March 17, 2011:
Thanks Brady, we’re this is priority for MI2.
-Tony
bradymiller wrote on Friday, March 18, 2011:
Tony and Ken,
Let me know when your ‘ken_icsa_clarify’ branch is ready for testing/commit. I can quickly package projects 1 and 2 stuff into one commit when its ready to go. The main question I have from looking at most recent changes that I noted the document encryption option is now off by default (ie. will turning this off make it not MU compliant?); this is your call, just want to make sure it’s ok.
-brady
lsalichs1 wrote on Friday, March 18, 2011:
I have been following the progress of OpenEMR certification for a long time and it is very exciting to see that it is very close to certified status. However, this detailed technical conversation is getting confusing. I guess the question many of us have is when will the certified status be achieved and when will there be a Certified Seal on the application?
tmccormi wrote on Friday, March 18, 2011:
Leaving it off by default is the better chioce. I’m testing it now, should be ready by this after noon. I have a screen/user tweak I want him to do, but it’s seems to be working well now.
-Tony
tmccormi wrote on Saturday, March 19, 2011:
Brady,
You can test it as is if you like, the screen change is just a better way to phrase the “download encrypted”. Ken won’t be able to get to that today and it can be a later update if we want to move on.
-Tony
bradymiller wrote on Saturday, March 19, 2011:
mukoya,
Don’t mean to ignore your always excellent input regarding bug testing and feature requests. Calendar code revision hasn’t been submitted yet. We’re shooting for a release next week, and we like code to get tested for awhile first so the calendar code will not make it in this release. There will likely be another release soon after 4.0 when we fulfill all the meaningful use criteria.
lsalichs1,
This is within the developer thread, which is why it’s so technical. Here’s another thread on this topic in the users forum:
http://sourceforge.net/projects/openemr/forums/forum/202504/topic/4413332
-brady
-brady
bradymiller wrote on Saturday, March 19, 2011:
Tony and Ken,
PROJECT 1 and PROJECT 2 are complete. Thanks for doing it so quickly.
You code tests and looks good overall, so committed it to sourceforge (the master and rel-400 branches):
http://github.com/openemr/openemr/commit/3262aea3026d4fadd0fae89d865d16391116e6af
Here’s are two commits I submitted after to fix some minor bugs in your code:
http://github.com/openemr/openemr/commit/9164d69f33ca79c2e00fa7711e1f1f21a2747dd6
http://github.com/openemr/openemr/commit/cce835db14e4a215e27aabd4d1fd97dc7765f8e3
-brady
bradymiller wrote on Saturday, March 19, 2011:
Visolve,
I know this may seem counterintuitive, but please ensure you keep doing your work for PROJECT 3 above on the icsa_clarify branch that I described above. It’s important that you do not merge, update or rebase your code to most recent codebase at this time. Just work and put your commits (for PROJECT 3) in the icsa_clarify derived branch and then I’ll easily be able to get them into the official codebase when your done.
thanks,
-brady
arnabnaha wrote on Saturday, March 19, 2011:
Brady…tony…Rod…and all…
First congrats on getting openemr certified and also getting to release 4.0.0….Really excited…!!! Its a request from my side to fix a small bug in the add facility screen as pointed out by many before the release…Congrats again….
Dr. Arnab Naha
bradymiller wrote on Saturday, March 19, 2011:
Another thing to note for Integration Developers (myself, stephen-smith, sunsetsystems, tmccormi),
Just a warning to avoid this mistake from ever happening. Never merge the master and rel-400 branches (this would completely screw up the sourceforge repository if you then pushed this merged branch to sourceforge). When bringing a commit from master over to rel-400 ALWAYS use cherry-pick. Just as I did for rel-320 in cvs, I am ok with being the only person who commits to rel-400 in order to avoid this from happening.
-brady
mukoya wrote on Saturday, March 19, 2011:
Brady,
Din’t think you would go for the kill so soon! When posting the issue regarding the calender, I thought it would be several months before official release.
Now that I see the target is so close, I guess I am more excited about the release than the calender!
Thanks all for great work.
Mukoya
kchapple wrote on Monday, March 21, 2011:
Brady et Al,
I have pushed testable changes to my github. Please see:
https://github.com/kchapple/openemr/tree/ken_icsa_clarify
Thanks,
Ken
visolveemr wrote on Tuesday, March 22, 2011:
Hi Brady,
We have pushed the SHA1 upgrade changes to our github and the same can be accessed from
https://github.com/visolve-selvi/openemr/commit/94f672c6bf5c73cf24fbbcd3cd1bed987c254c11
Thanks
ViCareplus Team
bradymiller wrote on Tuesday, March 22, 2011:
Visolve,
This looks great and tests well so I committed to the sourceforge master branch and rel-400 branch:
http://github.com/openemr/openemr/commit/bc71e33ade8db27e7f595df126382bd29ed1a467
Thank you for the contribution,
-brady
kchapple wrote on Tuesday, March 22, 2011:
OK, I have pushed a modification, which deletes the “converted” file upon the action of renaming a document. I started down the path of renaming, but this seemed to be safer, and I figured that users won’t be renaming files all the time, so shouldn’t affect performance too much. Please test, because I could not get imagemagick to work in the system, so I “simulated” its behavior.
https://github.com/kchapple/openemr/commits/ken_icsa_clarify
Thanks,
Ken
bradymiller wrote on Wednesday, March 23, 2011:
Ken,
Looks good and tests well. Just committed to both the master and rel-400 branches on sourceforge.
thanks for the contribution,
-brady