Patient Documents for portal and staff rework

I haven’t updated the dialog.js as of yet. but the issue is purely with the scrolling via touch screen. Once I connected a bluetooth mouse to my ipad, I was able to scroll up and down, and fill any fields, signature, etc. Will the dialog.js file fix whatever issue there is with touch scrolling?

Should. Worked for others.

@sjpadgett I downloaded the linked file and dropped it on the server @Hubtech is having the issue with. Did not resolve the issue.

Is this fix in the nightly build? I’ll test that in a snapshot.

Come to think of it your issue aren’t within dialogs though I fixed content height. However I’m pretty sure I fixed the issue with content height and scroll in portal along with other feature like button to hide sidebar.

I ported master portal to v6(3) which I’ll create a patch to get by until we release patch 3 if you’ll test from master and report back.

1 Like

Can confirm. I extracted the dev build over the top of my 6.0.0 patch 2 build and scroll works on iPads where it was not.

Reverting things, obviously. but can confirm it will work. A patch would be awesome.

@JaredBusch @Hubtech @hitechelp and others,
Attached is a v6 prepatch for v6(3) some notable fixes are:

  • portal stylings for IOS and new hide sidebar button.
  • portal PHP8 fixes
  • fix to prevent server php.ini session.gc_maxlifetime causing dreaded “Site ID missing from session” @hitechelp sorry I thought this was in patch 2!
  • Demographics message widget completed button now works
  • Billing DaySheet Report Fix.

Go forth and compute.:slight_smile:

BTW: Only apply this patch if previously have patch 2 applied. And there is not a requirement to run sql_patch and patched version in about is not changed.

v6_prepatch_3.zip (242.4 KB)

3 Likes

Works perfectly for our iPad issue. Thank you!

1 Like

Hopefully it will end the CAMOS errors in the Apache2 Error Log.

[Mon Aug 09 13:21:28.200877 2021] [php7:notice] [pid 7699] [client 192.168.1.147:52306] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 13:21:39.690732 2021] [php7:notice] [pid 7685] [client 192.168.1.147:52308] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 13:55:20.825446 2021] [php7:notice] [pid 8702] [client 192.168.1.147:52750] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 13:55:26.313657 2021] [php7:notice] [pid 8652] [client 192.168.1.147:52752] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 13:56:24.541246 2021] [php7:notice] [pid 8771] [client 192.168.1.147:52802] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 14:46:31.847868 2021] [php7:notice] [pid 9597] [client 192.168.1.147:53404] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 14:47:29.432326 2021] [php7:notice] [pid 9597] [client 192.168.1.147:53426] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 14:48:29.284971 2021] [php7:notice] [pid 9731] [client 192.168.1.147:53470] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 14:49:22.869275 2021] [php7:notice] [pid 9734] [client 192.168.1.147:53482] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 14:51:13.666136 2021] [php7:notice] [pid 9293] [client 192.168.1.147:53536] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 15:12:13.243801 2021] [php7:notice] [pid 10135] [client 192.168.1.147:53762] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS
[Mon Aug 09 15:15:32.954691 2021] [php7:notice] [pid 10132] [client 192.168.1.147:53836] OpenEMR CSRF token authentication error, referer: https://192.168.1.131/openemr/interface/patient_file/encounter/load_form.php?formname=CAMOS```

hmm, maybe.

Are you seeing issues with the form like saves or such? I.e. Is there a correlation between the notices and user frustrations?

I most certainly am. The errors all came from the same provider/machine.
I had one on my workstation as well, about 40 minutes prior to the log excerpts.
[Mon Aug 09 12:48:41.058430 2021] [php7:notice] [pid 6088] [client 75.74.23.156:59516] OpenEMR CSRF token authentication error, referer: https://23.24.175.201/openemr/interface/main/tabs/main.php?token_main= (Token redacted)

Question;
I extracted the pre-patch into the oemr directory but there were no instructions and no db patch sql in it. So, is that it?

That’s it.
Please open a different forum issue or a git issue for this as we’re coopting this thread. I’ll pay attention to this as I see occasionally on my dev system.
When open new issue please see if user can give a description of what else is going on such as several tabs open for different patients or any info relevant. This is very helpful for me to troubleshoot.

Anyway thanks David.

Ok, will do once I get a description from the Doctor.

Also, Pre-Patch calendar files are owned by root with root group and 0644 attributes. Is that Ok?
Reported Properties are;
File: /var/www/html/openemr/interface/main/calendar/add_edit_event.php
Type: PHP script, ASCII text, with very long lines, with CRLF line terminators
Size: 88.97 KiB Blocks: 184 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 35262615 Links: 1
Attrs: --------------e—
Access: (0644/-rw-r–r--) Uid: (0/root) Gid: (0/root)
Access: 2021-08-09 17:10:16.098620227 -0400
Modify: 2021-07-26 18:51:39.000000000 -0400
Change: 2021-08-09 17:05:51.140055002 -0400

No, group should be whatever group your instance is using like apache or such. 0644 is correct.
You shouldn’t unzip as a root user but whatever user account is elevated from root.

1 Like

Asked because other files in this directory have www-data / www-data as owner and group and I’m guessing the patch files should be the same.
I use Webmin to extract patches as it produces same file properties as doing “sudo unzip -o” from command line as in this example compared with my previous post above.

File: /var/www/html/openemr/interface/main/calendar/add_edit_event.php
Type: PHP script, ASCII text, with very long lines, with CRLF line terminators
Size: 88.97 KiB Blocks: 184 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 43254587 Links: 1
Attrs: --------------e—
Access: (0644/-rw-r–r--) Uid: (0/root) Gid: (0/root)
Access: 2021-08-10 07:30:44.428319063 -0400
Modify: 2021-07-26 18:51:39.000000000 -0400
Change: 2021-08-10 07:29:15.166479182 -0400

I always run a chown (permissions) and restorecon (SELinux) after all patches.

As this project is developed against Debian/Ubuntu you will almost always need to fix permissions if you are not on that.

I also never actually run as root, so always things with sudo.
I have an active deployment on Oracle Enterprise Linux 8. So I always do this:

[jbusch@openemr ~]$ sudo chown -R apache:apache /var/www/html
[jbusch@openemr ~]$ sudo restorecon -FR /var/www/html/openemr/

Jerry do you plan to have the document names display without the .tpl and the underscores convert to spaces at some point? Would make it more neat for patients.

Will you also be adding in file management to move files between general and repository?
And the ability to push documents from the repository to a patient? Not sure if it needs to copy the file, but maybe it could just become visible as a priority request in their forms section.

yes. currently I’m refactoring portal to get rid of sidebar(continuation of @benmarte work) and I’m doing some more work in documents for easier patient work flows plus some new feature.
This is much better as we gain lots more view port size.

2 Likes

Looks amazing, looking forward to seeing it. Will there be a prepatch nearer the time this is ready? Would love to try this out.

Depends on how different globals is but, I do plan to give out for testing soon.