Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No possibility to change the name of a Label Album #1123

Closed
JacquelinDV opened this issue Oct 19, 2021 · 14 comments · Fixed by LycheeOrg/Lychee-front#275
Closed

No possibility to change the name of a Label Album #1123

JacquelinDV opened this issue Oct 19, 2021 · 14 comments · Fixed by LycheeOrg/Lychee-front#275
Labels
bug Something isn't working

Comments

@JacquelinDV
Copy link

JacquelinDV commented Oct 19, 2021 •
edited
Loading

Detailed description of the problem [REQUIRED]

the structure of my albums are the following:
0 - Mes Petits enfants -- Physical Album
0.1 - Enfant1 -- Physical Album
0.1.1 - Petit enfant 1 -- Label album
......
Same structure for all my children.

Steps to reproduce the issue

Steps to reproduce the behavior:

  1. Go to 'Enfant 1'
  2. Click on 'Petit enfant 1'
  3. Scroll down to 'Rename'
  4. Modify the Name (for example: '1 - toto')
  5. Validate
  6. Go to 'Enfant 1'
  7. See error* "The name is not modified"
    Identical if
  8. Go to 'Enfant 1'
  9. Goto 'Petit enfant 1'
  10. Click on 'Petit enfant 1'
  11. Scroll down to 'Rename'

If I modify the name through phpMyAdmin: No Problem
Screenshots
If applicable, add screenshots to help explain your problem.

Output of the diagnostics [REQUIRED]

Diagnostics
-------
Warning: Dropbox import not working. dropbox_key is empty.
Info: Latest version of PHP is 8

System Information
--------------
Lychee Version (git):            master (2374a94) - Data not in Cache
DB Version:                      4.3.5

composer install:                --no-dev
APP_ENV:                         local
APP_DEBUG:                       true

System:                          Linux
PHP Version:                     7.4
Max uploaded file size:          500M
Max post size:                   500M
MySQL Version:                   10.2.40-MariaDB-1:10.2.40+maria~bionic

Imagick:                         1
Imagick Active:                  1
Imagick Version:                 1687
GD Version:                      2.3.0

Lychee total space:              98.20 GB
Upload folder space:             97.43 GB
System total space:              226.78 GB
System free space:               94.35 GB (41%)



Config Information
--------------
version:                         040305
check_for_updates:               1
sorting_Photos_col:              taken_at
sorting_Photos_order:            ASC
sorting_Albums_col:              title
sorting_Albums_order:            ASC
imagick:                         1
skip_duplicates:                 1
small_max_width:                 0
small_max_height:                360
medium_max_width:                1920
medium_max_height:               1080
lang:                            fr
layout:                          1
image_overlay_type:              exif
default_license:                 reserved
compression_quality:             90
full_photo:                      1
delete_imported:                 1
Mod_Frame:                       0
Mod_Frame_refresh:               30
thumb_2x:                        1
small_2x:                        1
medium_2x:                       1
landing_page_enable:             0
landing_owner:                   Jack
landing_title:                   Mes Albums
landing_subtitle:                Ma famille, mes voyages, mes amis...
landing_facebook:                https://www.facebook.com/JohnSmith
landing_flickr:                  https://www.flickr.com/JohnSmith
landing_twitter:                 https://www.twitter.com/JohnSmith
landing_instagram:               https://instagram.com/JohnSmith
landing_youtube:                 https://www.youtube.com/JohnSmith
landing_background:              dist/cat.jpg
site_title:                      Mes Photos
site_copyright_enable:           1
site_copyright_begin:            1900
site_copyright_end:              2021
additional_footer_text:          
display_social_in_gallery:       0
public_search:                   0
SL_enable:                       0
SL_for_admin:                    0
public_recent:                   0
recent_age:                      10
public_starred:                  0
downloadable:                    1
photos_wraparound:               1
map_display:                     1
zip64:                           1
map_display_public:              0
map_provider:                    Wikimedia
force_32bit_ids:                 0
map_include_subalbums:           0
update_check_every_days:         3
has_exiftool:                    1
share_button_visible:            1
import_via_symlink:              0
has_ffmpeg:                      1
location_decoding:               1
location_decoding_timeout:       30
location_show:                   1
location_show_public:            0
rss_enable:                      0
rss_recent_days:                 7
rss_max_items:                   100
prefer_available_xmp_metadata:   0
editor_enabled:                  1
lossless_optimization:           0
swipe_tolerance_x:               150
swipe_tolerance_y:               250
local_takestamp_video_formats:   .avi|.mov
log_max_num_line:                15000
unlock_password_photos_with_url_param: 0
nsfw_visible:                    1
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:         0

Browser and system

Browser: Chrome on Windows 10
@kamil4 kamil4 added bug Something isn't working JS - Lychee-Front labels Oct 19, 2021
@kamil4
Copy link
Contributor

kamil4 commented Oct 19, 2021

The bug is in the front end and it actually doesn't seem to have anything to do with tag albums; I can reproduce it with regular ones as well. I'll submit a fix shortly.

This reminds me though that you use this scheme where you move tag albums to other albums, turning them into subalbums. This is currently unsupported and works only by accident. Tag albums were meant to be "custom smart albums", listed only at the top level, together with other smart albums. It's a bug both on the front end side that it exposes the Move operation for such albums and on the server side that it allows such an operation to go ahead.

Still, since you clearly find this functionality useful, I guess we (the developers) should ask ourselves if we should properly support it, rather than having you rely on something that only works by accident and may break with the next version. @ildyria, @d7415, @nagmat84 -- what are your thoughts? Personally I've wondered from the beginning whether tag albums should be listed together with smart albums (as currently) or whether they should simply be mixed with the rest of user's albums, and available as subalbums and such. Although if we allow them as subalbums, shouldn't they work only on the content of their parent album then?

@kamil4 kamil4 mentioned this issue Oct 19, 2021
Merged
@ildyria
Copy link
Member

ildyria commented Oct 19, 2021

Although if we allow them as subalbums, shouldn't they work only on the content of their parent album then?

yes.

@d7415
Copy link
Contributor

d7415 commented Oct 19, 2021

I feel like this could get messy quickly (which I think was one of the reasons for making them top level). Operating only on the contents of their immediate parent probably makes sense.
I suppose mixing/separating could be an option, at least within the parent.

@kamil4
Copy link
Contributor

kamil4 commented Oct 19, 2021

Yeah, it's already messy: the front end is grossly mishandling various special cases, such as the smart albums and tag albums. Check the options that show for them in the "+" menu, the pop-up menu... We need a big clean-up of all that stuff, unless the new front end is ready soon.

I am particularly interested to hear from @nagmat84 how his new album structure from #1101 would affect the prospects for "tag subalbums".

@nagmat84
Copy link
Collaborator

I am particularly interested to hear from @nagmat84 how his new album structure from #1101 would affect the prospects for "tag subalbums".

In principle it should be doable. It probably should be even easier than before but I agree with @d7415 that there will like by many cases (in particular when it comes to rights management) which thoroughly need to be taken into account.

Personally, I don't see the point in tag albums anyway and I don't use them. To me they feel like a fifth wheel. IMHO, there are two different approaches how photos can be organized:

  1. "Tag albums only": One has a huge pile of photos and one assigns tags to them. Alongside one has a hierarchy of tag albums and photos appear in albums based on their tags. (Note, we don't fully support that yet, because tag albums cannot be arranged hierarchically).
  2. "No tag albums at all": The system as it is provided by Lychee right now minus the tag albums. Because photos are not really duplicated when they are put into more than one album, photos can be copied into as many albums as you whish and therewith achieve the same result as with tags.

I don't see the additional benefits of tags. For example my personal Lychee installation is organized as follows

                                +-- Alice
                                |
            +-- Family ---------+-- Bob
            |                   |
            |                   +-- Charlie
            |
            |                   +-- Dora
            |                   |
People -----+-- Friends---------+-- Emil
            |                   |
            |                   +-- Faye
            |
            |                   +-- Dora
            +-- Acquaintances --+
                                +-- Henrik

            +-- Karlsruhe -- ...
            |
            +-- Stuttgart -- ...
Locations --|
            +-- Paris -- ...
            |
            +-- ...
            

            +-- Christmas 2021
            |
            +-- Vacation Trip 2019
Events -----|
            +-- Tom's Birthday 2020
            |
            +-- ...

If I have a photo of Bob, Emil and Hendrik which was taken at Tom's birthday in Karlsruhe, then it goes into the albums Bob, Emil, Hendrik, Karlsruhe and Tom's birthday. I think you get the idea. I personally haven't found a use case for tag albums which can not be covered by normal albums only. But I am curious to hear, if someone can come up with one.

So, I would be glad if we could drop the support for tag albums completely. Personally, I don't think the provide a benefit which is worth the effort to support them. Or more precisely, I don't see the point in maintaining two different approaches of photo organization simultaneously which IMHO strangely interact with each other. As "normal" albums are more mature and "tag albums" are missing some feature, I would not hesitate to drop the latter.

But, if persons strongly want to keep tag albums and even may have good use cases for them, then I am also willingly to help to improve them.

@JacquelinDV
Copy link
Author

JacquelinDV commented Oct 20, 2021 via email

@nagmat84
Copy link
Collaborator

nagmat84 commented Oct 20, 2021 •
edited
Loading

Thanks for your quick response. But I fail to understand why your use case requires tag albums at all. You can have the same photo in multiple albums without multiplying storage requirements. So you can have the same photo, e.g., in "family events" and in "petit-enfant 1". This is exactly what I do, too
You don't need tags for that.

Moreover, I don't understand what you mean by the hierarchy of tag albums is [your example here]. Momentarily, it is not possible to have a hierarchy of tag albums.

I assume we are talking about different things.

@kamil4
Copy link
Contributor

kamil4 commented Oct 21, 2021

For a bit of history, the tag album feature was implemented a little over a year ago in #704 by an external contributor. A request for such a feature dates back two years prior, to #48. The ability to add tags to pictures and search for them is even older than that.

I don't use the tag album feature in my gallery either but I'm against removing it; instead, I think we should make it more general. After that feature was added, we've had a fair number of inquiries/improvement proposals related to it, so clearly there is an interest in that sort of functionality in the user community.

When tag albums were first added, I thought of them as "saved searches", which didn't seem all that useful to me, but that's apparently not how some want to use them. They want to have different ways of grouping the same collection of images. One user complained to us that he wanted to make only a subset of pictures from an album public. We can't do that at the album level; it's all or nothing. So he thought that he could make the subset of pictures individually public and then present them in public mode via a tag album. Only tag albums didn't include individually public pictures then; that's how public_photos_hidden was born. Users have diverse needs and can be creative about how they meet them; we shouldn't stifle their innovation.

Yes, a similar effect can be achieved via regular albums and "Copy to...", but I feel that that misses the point a bit. Convenience matters. For instance, "Copy to" creates a new Photo object, so later changes to editable metadata such as the title or description don't get propagated to the copies. What if the user later decides to delete the image from the gallery for some reason? They need to remember that they copied it to other location(s) and manually delete all the instances. It's a hassle. With tags, I believe it's even possible to initialize them from EXIF metadata during import, which could be a huge productivity boost for somebody importing an already tagged collection of images. People may simply be used to the concept of tag albums from other photo galleries.

@kamil4
Copy link
Contributor

kamil4 commented Oct 21, 2021

Anyway, @JacquelinDV, until this bug gets fully resolved, a workaround for you is to hit Reload in your web browser right before renaming an album. It should work then.

@JacquelinDV
Copy link
Author

JacquelinDV commented Oct 21, 2021 via email

@kamil4
Copy link
Contributor

kamil4 commented Oct 21, 2021

It takes 28s to generate a list of 950 albums on your maybe not top-tier, but certainly not ancient hardware? Wow! That is bad. How deep is your album hierarchy typically? Is it three levels deep, as you indicated in your previous messages?

@JacquelinDV
Copy link
Author

JacquelinDV commented Oct 21, 2021 via email

@kamil4
Copy link
Contributor

kamil4 commented Oct 21, 2021

Thank you. I ran some experiments here as well and I'm actually seeing timings on the order of 50 seconds for 1,000 albums. This is something that we should try to improve, but as it's not directly related to this issue, I created a new one: #1124.

@nagmat84 nagmat84 mentioned this issue Oct 22, 2021
Closed
@JacquelinDV
Copy link
Author

JacquelinDV commented Oct 22, 2021 via email

@kamil4 kamil4 mentioned this issue Nov 1, 2021
Merged
@nagmat84 nagmat84 mentioned this issue Nov 14, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Don't rely on albums.getByID() LycheeOrg/Lychee-front
5 participants
@ildyria @d7415 @nagmat84 @kamil4 @JacquelinDV