view-schedule.php hide label -> privacy config (GDPR) not working from v2.8.2 again

[QuasiMoko]

Hi,
I'm really sad about notice EOL of booked, when I wanted to upgrade my installations for some non profit organisations. So I'm very happy finding this amazing project be forked :-) (congrats to @nkorbel too for his fantastic work and personal effort until here, THX a lot).

Here's the Issue:
In view-schedule.php the reservation label is showing (privacy data instead hiding it).
The popup is 'blocked' correctly.

This bug was already fixed in an older version by Nick. I used v2.7.7 at least, it was fine. After upgrading directly to v2.8.5.3 I got it again. Now I upgraded step by step and found the bug occours again with release change v2.8.1 -> v2.8.2 again.

Some of my configs I'm using might help:

$conf['settings']['schedule']['show.inaccessible.resources'] = 'true';  // whether or not resources that are inaccessible to the user are visible
$conf['settings']['schedule']['reservation.label'] = '{att7}: {title} - {name}';    		// format for what to display on the reservation slot label.  Available properties are: {name}, {title}, {description}, {email}, {phone}, {organization}, {position}, {startdate}, {enddate} {resourcename} {participants} {invitees} {reservationAttributes}. Custom attributes can be added using att with the attribute id. For example {att1}
$conf['settings']['schedule']['hide.blocked.periods'] = 'false';    	// if blocked periods should be hidden or shown


/**
 * Privacy configuration
 */
$conf['settings']['privacy']['view.schedules'] = 'true';       			// if unauthenticated users can view schedules
$conf['settings']['privacy']['view.reservations'] = 'false';    			// if unauthenticated users can view reservations
$conf['settings']['privacy']['hide.user.details'] = 'false';    			// if personal user details should be displayed to non-administrators
$conf['settings']['privacy']['hide.reservation.details'] = 'false';			// if reservation details should be displayed to non-administrators. options are true, false, current, future, past
$conf['settings']['privacy']['allow.guest.reservations'] = 'false';			// if reservations can be made by users without a Booked account, if true this overrides schedule and resource visibility

Especially not hiding sensitive personal user information (like name, email, phone etc.) in public installations is a problem.

Unfortunately my coding skills are not good enough to fix it myself. I tried unsuccessfully yet.

I'd appreciate someone could handle it or have an idea.
At this times the system became very helpful to comply with corona virus regulations for us.

Thanks a lot

PS: I'm not sure, couldn't test it really yet. I may found some signs for a similar privacy issue in the ical-integration with this set-up.

[effgarces]

Thanks for the report, especially for finding were the issue started to occur. I'm going to look into this as soon as I can.
If you detect(ed) similar issues let us know, everything that has to do with GDPR in europe is a big deal.

[QuasiMoko]

That sounds very good.

I reviewed some docs, so the key point should be this setting, that is not working (the others i mentioned above should work fine):
$conf['settings']['privacy']['view.reservations'] = 'false';

Public Schedule Visibility
By default only logged in users can view schedules, but this can be changed with some configuration updates.

In Application Configuration the privacy section contains two settings – view.schedules and view.reservations.

view.schedules will allow unauthenticated users to browse your schedules, though they will need to log in to book any resources. A new menu option on the login page will be displayed to let users open the schedule in a read only mode.

view.reservations lets you control whether or not unauthenticated users will be able to see reservation details from the read only schedule. By default, only available and unavailable times are shown. Setting this to true will show full reservation details to unauthenticated users.

May it helps you

[effgarces]

yes, every little bit of info is helpfull, I will get around this issue over at the weekend (I hope)

[effgarces]

I just added a fix to the develop branch, that should take care of this issue, if can test it and report back it would be great, just replace the lib/Application/Schedule/SlotLabelFactory.php with the one on the develop branch and you should be good to go.

By the way while investigating this issue I've noticed that sometimes a label saying "Private" replaces the private data, but in certain situations the label is simply blank and while this is not a showstopper issue it's annoying. The issue is on the exact same place that the fix was added, so in a nearby future I hope to take a closer look at that file/function and make it neater.

[QuasiMoko]

Hi, as far as I could test at the moment with my config...it looks fine.
The SlotLabelFactory class is also used for Web/monitor-display.php, so the bug is fixed there too...great.

Thanks a lot for your quick support

PS (off-topic): A little annoying is, that the config.php will be cleared from all comments during config-update while System-Upgrade and new config-entries are not just added at the end.

[effgarces]

Nice, glad it's working for you, I've also implemented it in our installs and seems to be working ok.

I've noticed that the comments were stripped, but I never went to look why was that, oh well now my ocd won't let me stop looking at the file. I don't know how long it will take to get to that issue, there's alot of things needing attention before, but everytime that I open that file it will remind me of it.