Sensitive album contents appear in search results and in Recent smart album

[vjuliano]

Detailed description of the problem [REQUIRED]

Not sure if this is a bug, but it is not what I would expect to happen. The contents of albums marked sensitive are shown in the Recent smart album. I mark images sensitive because I dont want them just showing up at possibly less than opportune moments.

Steps to reproduce the issue

Steps to reproduce the behavior:

1. Upload a new photo
2. Add it to an album marked sensitive
3. Go back to gallery and open Recent
4. Image is displayed

Screenshots
If applicable, add screenshots to help explain your problem.

Diagnostics
-------
Warning: Dropbox import not working. dropbox_key is empty.




System Information
--------------
Lychee Version (git):            master (a7de020) - Data not in Cache
DB Version:                      4.4.0

composer install:                dev
APP_ENV:                         production
APP_DEBUG:                       true

System:                          Linux
PHP Version:                     8.1
PHP User agent:                  Lychee/4 (https://lycheeorg.github.io/)
Max uploaded file size:          500M
Max post size:                   500M
Max execution time:              200
MySQL Version:                   10.5.13-MariaDB-0ubuntu0.21.10.1

Imagick:                         1
Imagick Active:                  1
Imagick Version:                 1691
GD Version:                      2.3.0




Config Information
--------------
version:                         040400
check_for_updates:               1
sorting_Photos_col:              id
sorting_Photos_order:            DESC
sorting_Albums_col:              max_taken_at
sorting_Albums_order:            DESC
imagick:                         1
skip_duplicates:                 1
small_max_width:                 0
small_max_height:                360
medium_max_width:                1920
medium_max_height:               1080
lang:                            en
layout:                          1
image_overlay_type:              none
default_license:                 CC-BY-NC-ND-4.0
compression_quality:             90
full_photo:                      1
delete_imported:                 1
Mod_Frame:                       1
Mod_Frame_refresh:               30
thumb_2x:                        1
small_2x:                        1
medium_2x:                       1
landing_page_enable:             1
landing_owner:                   Vincent Juliano
landing_title:                   Life on 35mm
landing_subtitle:                Click top right to continue.  Next page top left to login
landing_facebook:                
landing_flickr:                  
landing_twitter:                 
landing_instagram:               
landing_youtube:                 
landing_background:              /uploads/medium/3d4bf4e35e5ea06853d7983c88efb6a2.jpg
site_title:                      Vince Juliano's Photo Gallery
site_copyright_enable:           1
site_copyright_begin:            2021
site_copyright_end:              2021
additional_footer_text:          "Alex's Photos" copyright Alex Panicacci 2021
display_social_in_gallery:       0
public_search:                   0
SL_enable:                       0
SL_for_admin:                    0
public_recent:                   0
recent_age:                      60
public_starred:                  0
downloadable:                    1
photos_wraparound:               1
map_display:                     1
zip64:                           1
map_display_public:              1
map_provider:                    Wikimedia
force_32bit_ids:                 0
map_include_subalbums:           1
update_check_every_days:         3
has_exiftool:                    1
share_button_visible:            0
import_via_symlink:              0
has_ffmpeg:                      1
location_decoding:               1
location_decoding_timeout:       30
location_show:                   1
location_show_public:            1
rss_enable:                      0
rss_recent_days:                 7
rss_max_items:                   100
prefer_available_xmp_metadata:   0
editor_enabled:                  1
lossless_optimization:           1
swipe_tolerance_x:               150
swipe_tolerance_y:               250
local_takestamp_video_formats:   .avi|.mov
log_max_num_line:                1000
unlock_password_photos_with_url_param: 0
nsfw_visible:                    0
nsfw_blur:                       0
nsfw_warning:                    0
nsfw_warning_admin:              0
map_display_direction:           1
album_subtitle_type:             oldstyle
upload_processing_limit:         4
public_photos_hidden:            1
new_photos_notification:         1

Browser and system

Mac OS 11.6.2 Firefox 95.0.2

[vjuliano]

Not sure if this is related to #1155

[nagmat84]

No it isn't related to #1155. The other issue is about hidden albums which require a direct link in order to be accessed. This issue is about sensitive albums. These are two different things.

While #1155 will be "automatically" fixed when my big PR is merged into master, the behavior with respect to sensitive albums will not change.

At the moment the backend does not deal with sensitive albums in any way. The backend always sends sensitive albums to the frontend together with any other albums. It is the frontend which makes them invisible until one presses the H key.

[nagmat84]

Edited the title to indicate that search results are also affected. Under the hood, the search feature and the the Recent album use the same code. The Recent album is nothing more than a special kind of search.

Moreover, I closed #1176 as a duplicate of this issue.

[vjuliano]

An additional issue I found which is related to this is, sensitive albums are included in the notifications emails that get sent. This is not behavior I would expect for a hidden album marked sensitive.

[ildyria]

If the album is marked as hidden, I would agree that there should not be notification sent in that regard.

However being sensitive has nothing to do in that regard IMHO. :)

[vjuliano]

The album is marked as hidden and was included in the notification emails. What functionality does marking an album as sensitive actually control?

[ildyria]

This was integrated in #822

Thus this PR implements NSFW albums.

• adds a new "flag" so that such folders can be recognized at first glance while being logged in.
• adds a key-bind H which hides all folders previously marked as sensitive.
• adds a pink star in the header to notify the user is in a Sensitive folder.
  Changing this property is either done on clicking on the star or toggling it in the visibility parameters.
  makes it possible to hide Sensitive folder by default.

So non-displayed sensitive albums can always be revealed with the H key (unless they are marked as hidden).

The reason for this was the following:

In my case, I had to open the admin view while my parents were behind my back, having folders such as "Boudoir" etc can be tricky to explain.

[vjuliano]

All the functionality listed there seems to work as expected. The issue is that even while hidden, the hidden sensitive albums and their contents will display in search results and be part of the email notifications. This seems to only happen for users with permissions to see the albums, but can lead to contents being displayed at unexpected moments.

[nagmat84]

As I already said, the server has no knowledge wether the sensitive album is visible or not as the key press H is evaluated on the client-side only. (Please don't call that visibility state "hidden", because "hidden" is something different.)

We have understood the problem, we can reproduce it and yes, I agree, that this situation should be improved. There is no need to repeat the same issue description over and over again.

To my fellow developers:

As a first solution we should probably introduce two new configuration settings: include_sensitive_albums_in_notifications and include sensitive_albums_in_search. This would at least allow to configure the behavior at the backend-side on an application-wide level.

For the search, only applySearchabilityFilter needs to be improved to honor this setting.

In the long run, we could also extend the API call /api/Search::run by an input parameter which tells the server on a per-search basis whether sensitive albums should be included or not. This way the client could report the current state of the H key to the server.