Time to discuss version 4 release plans. There are a couple of options as I see it and a couple of requirements, I think. Starting with the requirements:
1) We need review and merge the mu-cert-p1-icsa-approved branch into the master. It needs review and a bit more testing as we had to rush the process a bit due to the scheduling of the tests. It is fully functional, but may need some tweaks etc .
2) Once merged we need to tag or otherwise make it possible to get the integrated branch running as a regression test point to make sure we don’t break something in subsequent development
I’m leaning toward #1 option but I’m good with what the community decides, and, as Brady is the usual point man in releases his opinion is critical here, I’d say.
Congratulations to everybody involved. Very cool. Agree with releasing with what we now have (this was the plan Stephen discussed awhile back). Might as well create a rel-400 branch off master/tip and get a Online Developer Demo going for it. I should be able to accomplish this tonight. Tony, the bottleneck will be getting the mu-cert-p1-icsa-approved projects to master/rel-400. Best to do them in projects rather than as a whole (I think there’s only the sha doc stuff, doc encrypt stuff, and visolves md5/sha1 stuff, but not sure). Will be easier to get them as separate projects (I’m guessing the sha doc stuff is already to go since it’s already been posted in the forums). Please list off the projects that need to be merged to see where we stand.
The mu-cert-p1-icsa-approved has two commits one is the Doc Encrypt/Decrypt and the other is Visolve’s MD5 to SHA changes. Should be able to cherry-pick those and merge them in, I’d say.
Ken’s original SHA Hash post is up, but it was integrated (by Visolve) into the branch. Unfortunately Devi posted a clone of openemr repo instead of a fork+branch so I add to pull their changes into the test branch as a tarball…
Maybe Visolve can correct their original post and get it correctly on github? I didn’t have time to do that on Monday.
Let me know what you want me to do, I’ll do my best to help sort it out.
I am not in the US, (No incentives for me:-)) but from my reading regarding EHRs, this certification appears to be a big step.
Congratulations to all that contributed to this.
Small request: OEMR 4.0 appears quite stable. been using the new calender and is good except for an issue or two ( in fact my only issue was background color for “add new event” and “edit event” popup which I resolved by replacing a color, i think “DDDDDD” with “Mycolor” in Interface/main/calender/add_edit_event).
Could we at least include this code in the final 4.0?
Hey, regarding the calender issue, II am aware that the danger in trying to satisfy everyone is that you go round in circles indefinitely and still not succeed. For this reason, i will go with community decision, new calender or not though I personally would prefer it included if it wont take too long.
Need to separate these into projects.
Visolve’s branch above changes a bunch of file permissions and also removes some unrelated code. I separated all three of the modules here: http://github.com/bradymiller/openemr/commits/icsa_clarify
(note that the diff of this branch is the same as visolve’s above branch minus the file permissions changes and the removal of previous code - so no features are lost)
Below are links to the commits for each project in the branch.
Quick overview/testing:
Project 1 likely looks good to go.
Project 2 throws a white screen a death bug if try to encrypt file and is buggy.
Project 3 will not be acceptable until it works for upgraders (it is not acceptable to reset all users upgraders passwords to ‘pass’)
(plan to do more testing/review hopefully within next couple days; hopefully visolve will improve their code for upgraders in the interim)
For the integrators ensure you push to the correct sourceforge branch (ie. don’t mess up master vs rel-400 or you’ll merge them together); may be best that I only do the commits to rel-400 to avoid issues right before the release.
Brady,
You are a god. :-) Thanks, I’ll get Ken to look at the project 2 branch. It requires php5_mcrypt be installed, might need to do that on the demo server or your system, it will be required. He is also working an FAQ on how the work flow goes, I didn’t find any issues/bugs with it during our tests, but they were a bit short.
CRITICAL BUGS:
1) If you rename a file to something that already exists, then very bad things happen (ie. you basically are deleting a document!!). Suggest utilizing same mechanism in the upload docs script to deal with this (it has a function that checks and iterates the filename if it already exists automaticall).
2) For upgraders, if the hash is set to NULL, then a validation will show the file has been compromised (options include hiding option exist if no hash exist, or an option to create a hash for the future etc.)
MINOR BUG:
1) Put a blank line between “Sha-1 Hash” line and the “Update” line in the documents screen.
CRITICAL BUGS:
1) You have removed a major feature (embedded viewing of documents, so now need to Download every document to see it). Obviously, you need to put this feature back.
2) On document view screen, if click encypt with a pass phrase I get a file that is empty (0 bytes) and getting this error in log:
PHP Warning: fopen(/tmpencrypted_salinaandbrady.jpg): failed to open stream: Permission denied in /var/www/openemr/controllers/C_Document.class.php on line 320
MINOR BUGS:
1) In the upload document page, place a blank line between “Optional Destination Name” and “Encrypted File?”
2) Rather than show “Supports TripleDES encryption/decrpyption only. Leaving the pass phrase blank will not encrypt the document.”, consider making it a title element (so see if drag on top of it); otherwise it just seems kind of awkward and takes over the screen by a feature that most will never use; if can figure out another way to not confuse users (maybe put further down on screen) then go for it. Also need to fix misspelling of decryption.
3) If click on ‘Encrypt’ with a blank Pass Phrase then throw a javascript alert error (ie. validate it).
4) On upload screen, suggest changing Encrypted File to “Is the file encrypted?”
5) On the document view screen, suggest changing the “encrypt” link to “download encrypted file” or something more clear that you are in fact downloading an encrypted file and not actually encrypting the main file.
(Notably this patch actually fixes the minor bug in the SHA1 patch (project #1) regarding spacing between “Sha-1 Hash” and “Update”)
Also note it requires the php5-mcrypt module on ubuntu, and the demos have already been modified to support this code when it’s ready to be committed. Again, address above bugs, and it’s ready to go.
CRITICAL BUG:
1) Need a better upgrading scheme. Recommend the following scheme: On a user’s first login, will return a warning “Password security has recently been upgraded. Please login again.” When the user logs in again, his/her password will automatically of been converted to SHA1 (on the first login).
Took this from folliwng discussion page: http://www.simplemachines.org/community/index.php?topic=84553.0 Do agree with making the pwd_history1 and pwd_history2 empty for upgraders.
Please make the above code revisions top priority. Strategically, we need to get a production version out when it becomes known that OpenEMR is certified. Propose the following timeline; the Above 3 ICSA Projects revised and committed by Friday(Tony’s group on 1 and 2 and Visolve’s group on 3). Then one week of testing on the online demo and release 4.0 next weekend. I don’t mean to bark orders or anything, but I’ve contributed lots of time recently (setting up demos, organizing icsa commit, and reviewed icsa commits) to get this going for a reason (ie. we need to take full advantage of this certification by getting an official release out).
For the developers working on the three above projects, work off the following branch:
git add remote brady git://github.com/bradymiller/openemr.git
git checkout brady/icsa_clarify
git checkout -b local_icsa_clarify
Then place your commits in this branch and push them via (assuming your public repo is ‘origin’):
git push origin local_icsa_clarify
It’s ok to rebase your newly created commits, but do not touch the commits that already exist there. This will then make it much easier for me to reorganize/compile these commits per project when we put them into the official codebase.
Geez, it’s late; i forgot the fetch command. Here’s the full list of correct commands to get the branch:
git remote add brady git://github.com/bradymiller/openemr.git
git fetch brady
git checkout brady/icsa_clarify
git checkout -b local_icsa_clarify
