Situation
When I print service notes a generic date appears above every service note post upgrade to 7.0.2
OpenEMR Version
I’m using OpenEMR version 7.0.2
Browser:
I’m using: Chrome and Edge
Operating System
I’m using: Windows 10 - 11
Search
Did you search the forum for similar questions?
Logs
Did you check the logs? yes
Was there anything pertinent in them? No
Please paste them here (surround with three backticks (```) for readability.
You can also turn on User Debugging under Administration->Globals->Logging User Debugging Options=>All
Hi,
did you ever figure out what was causing this issue? I suspect it is a data issue not a code issue.
There are no errors of any kind being thrown in the system.
Sherwin,
This will be hard coded somewhere I suspect in layout options.
I’d search repo history for any commits in options.
I’m really busy but if I get a quick minute, i’ll track it down.
@sjpadgett it is a data issue. I was able to make it go away by checking for an empty date.
Wrap line 787 in an if statement.
Wrap it like this to patch the issue.
// show the encounter's date
if (!empty($dateres["date"])) {
echo "(" . text(oeFormatSDFT(strtotime($dateres["date"]))) . ") ";
}
It treats the symptom but not the root issue.
There is a 0 being passed into this function from the
function getEncounterDateByEncounter($encounter)
{
global $attendant_type;
$table = $attendant_type == 'pid' ? 'form_encounter' : 'form_groups_encounter';
// $sql = "select date from forms where encounter='$encounter' order by date";
$sql = "SELECT date FROM " . escape_table_name($table) . " WHERE encounter = ? ORDER BY date";
return sqlQuery($sql, array($encounter));
}
It will take some time to get down to the root of the sqlQuery that is not filtering out the empty encounter.
nice troubleshooting Sherwin but it’s still a code issue not database. Spitting hairs still a good catch.
I didn’t read issue to see that its in custom report. I was thinking layouts.
@sjpadgett I have to agree it is a code issue. I have spent time going over the data and can’t find a newpatient encounter with no encounter number. I don’t know if I should spend any more time tracking down the bug since the behavior produced by the bug has been mitigated. This should be good enough for now. I will open a PR today.
Thanks Sherwin, please keep me updated on the pull request!. And when you get time to get down to the root of the sqlQuery that is not filtering out the empty encounter.