New billing Manager with new method of search criteria.Compared to the previous one there are a lot many filtering options.
The search criteria is made in such a manner that with minimal code new criteria and criteria options can be added.
We have sent a copy to Tony and he proposed to submit it to Git for approval.
The following tracker is used for upload:- https://sourceforge.net/tracker/?func=detail&aid=3150337&group_id=60081&atid=1245239
The patch file is uploaded with name
‘0001 New billing Manager with new method of search criteria.patch’
and one image(interface/pic).
A documention is also uploaded for how the criteria are managed.
The comments said during the time of first commit is coded.
Individual tabs(mainly used for indenting) are replaced by 4 spaces.Old and new areas all are replaced.
Copyright is edited.Now Company name is set to “Z&H Consultancy Services Private Limited” and year is 2011.
2 xl() calls are corrected by removing variables from it.
I just tried out the billing manager. The functionality is really nice and convenient. Very nicely done.
However, I did a test upgrade to v4.0 from v.3.2 and did the sql_upgrade and acl_upgrade (forgot to do it the first time but then remembered, but still get the same result)… we get the following error:
ERROR: query failed: select distinct billing.id, form_encounter.date, billing.pid, billing.code_type, billing.code, billing.user from form_encounter, billing, patient_data, claims, insurance_data where billing.encounter = form_encounter.encounter and billing.pid = form_encounter.pid and patient_data.pid = form_encounter.pid and claims.patient_id = form_encounter.pid and claims.encounter_id = form_encounter.encounter and insurance_data.pid = form_encounter.pid and insurance_data.type = ‘primary’ AND (form_encounter.date between \\‘2011-01-07 00:00:00\\’ and \\‘2011-01-07 23:59:59\\’) AND billing.billed = '\\‘0\’ and billing.code_type like ‘%’ and billing.activity = 1 order by billing.pid, billing.date ASC
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\\‘2011-01-07 00:00:00\\’ and \\‘2011-01-07 23:59:59\\’) AND billing.billed ’ at line 1
" The problem is the backslashes that are embedded in the query line.
It might be a php.ini configuration issue.
In the php.ini magic_quotes_gpc must be Off …"
Ouch this conflicts then with another portion of OpenEMR. In fact, we turned magic quotes on because some of the adjustments reasons in the EOB section of the program require it in order for them to insert correctly.
This goes against that. We were going to attempt to fix it but realized really quickly that the adjustment reasons are a lot more integrated into the program than one would think.
I tested the “to ded’ble” adjustment on ver 3.2 and it doesn’t work unless magic quotes is on. I just tried it in version 4.0 and it works with magic quotes being off.
Rod Roark was the first to point out that not supporting Magic Quotes “On” or “Off” is a poor programming practice or “bug”. This Magic Quotes bug should be in the coding guidelines as it was extensively discussed by Rod Roark, Andres Paglayan and James Perry, Jr in the early OSMS board meetings. The actual recommended default setting is Magic Quotes “off” because a lot of older sections of code required this setting and would not correctly function without this selection. Chris I know you understand this already but explain it here for the non-developers who read these posts. The reason is, that if the developer starts with his own Magic Quotes “On” (or OFF) then his or her software will only run correctly on her or his own local installation. The problem is invisible to the local developer but easily apparent to an installation with the opposite setting.
Chris, it sounds sounds like you have discovered one of the bugs concerning this issue and hopefully can apply a fix for the section of code where you discovered this?
The “Magic Quotes bug” should have been documented in the coding guidelines worked out by the OSMS board? These guidelines are here for developers who have insomnia, 2 AM indigestion or are new to the project. Also if you have been in the project for awhile but haven’t seen these before, you might ought to look them over:
The OSMS board has been directing the software development, direction and guidelines since October, 2005. The senior project developer, Rod Roark, personally recommended many of these policies during the many, long, board meetings over the last five years. I had to sit through through them all and take notes on this. Since 90% of the discussions in these meetings were about software development, policies and direction for the OpenEMR project.
Rod has made a huge impact on the project and I for one have always been very glad he was in these board meetings to help guide us with his extensive development experience. In fact, I believe he been perfect in his attendance of the meetings and he should be commended for this.
Actually I had remembered reading about how Magic Quotes is a security threat. I quickly searched and I was correct. PHP.NET advises against using Magic Quotes and has decided to deprecate the feature in PHP 5.3.0.
More reading about the security holes associated with Magic Quotes here:
We do advise against using Magic Quotes, but Brady is also correct: development policy is that code should work with it either on or off, and failure to do so is a bug.
It is a bug to not support both magic quotes off/on.
There was a lot of work done around the 3.1/3.2 releas so the code “worked” when magic quotes is off. Try out 3.0 or 3.1 code with magic quotes off, and see what happens when you put apostrophes into the fields; they basically cause sql errors, database corruption(apostrophes disappear), and the searches do not work. Here’s the project that worked on that back then: http://www.openmedsoftware.org/wiki/Active_Projects#Clean_up_magic_quotes.2C_prevent_sql-injection.2C_and_prepare_for_PHP6
There are still likely places where apostrophes are not supported when magic quotes are off (for example relateively recently converted the bottom left seach field and the transactions modules to the new security model because apostrophes broke it). We are likely not ready to confidently state that setting magic quotes to off will work (start putting apostrophes into all the OpenEMR fields and I’m guessing you’ll find some places thatr still break).
So, to state that we have been officially recommending magic quotes off is nor entirely accurate, because we have been in fact (at least practically) recommending this to be turned on (if you ever want to use apostrophes in your fields). Sam, look back at your original XAMPP package you created; not is has magic quotes set to on.
If you don’t support both:
1. It is a security risk
2. It is a data corruption risk
This is a general php issue, and projects use an assortment of tools/mechanism to deal with this. We actually have two mechanisms:
1. For previous scripts, the library/formdata.inc.php functions
2. For new scripts, use the new security model (note can also convert old script to this, of which several examples are listed in below wiki site): http://www.openmedsoftware.org/wiki/Active_Projects#PLAN
I think magic quotes are evil (as do all php developers). But you can’t ignore them. I develop in an environment with them off, but I test my code with them off and on. They can be elegantly managed via centralized functions that use get_magic_quotes_gpc() (which is what our two current mechanisms do). It’s vital to centralize these functions, in order to make transition to php6 easier in the future. Because php6 will not even allow this function anymore, but if completely centralized then easy to run php6 specific code vs. pre-php6 code.
We checked the combination of slashes and quotes both when Magic Quotes is on or off.
Actually the stripslashes_deep work only when the magic quotes is on because we are using the openemr function strip_escape_custom.
In strip_escape_custom() there is the check for magic quotes.
Our result is as shown below.
Magic quotes off
1)Given in screen
Patient Name = a’b’‘c’’'d\e\\f\\\g
What getting internally
2)Request value
—
patient_data.fname like ‘a’b’‘c’’‘d\e\\f\\\g%’
3)Request value after stripslashes_deep
—
patient_data.fname like ‘a’b’‘c’’‘d\e\\f\\\g%’
4)After add_escape_custom().Given to query
--------
patient_data.fname like ‘a’b’‘c’’‘d\\e\\\\f\\\\\\g%’
===========================================================================================
Magic quotes on
1)Given in screen
Patient Name = a’b’‘c’’'d\e\\f\\\g
What getting internally
2)Request value
—
patient_data.fname like ‘a’b’‘c’’‘d\\e\\\\f\\\\\\g%’
3)Request value after stripslashes_deep
—
patient_data.fname like ‘a’b’‘c’’‘d\e\\f\\\g%’
4)After add_escape_custom().Given to query
--------
patient_data.fname like ‘a’b’‘c’’‘d\\e\\\\f\\\\\\g%’
sorry. Overlooked the use of strip_escape_custom. The main issue is that this is yet another mechanism to deal with magic quotes, however will be very easy to “migrate” this mechanism in the future to the new security model (if that ever happens). I’ll commit it (but I’m gonna add a quick comment to flag the line for the future).