Search: Show which albums a photo belongs to

[mmaravillo]

This is an initial attempt to address Issue #373 to display the album list in the Card view.

Hopefully this avoids the issue on performance by using a LEFT JOIN, instead of an additional query to get the album list for each photo search result. The extra rows returned by the LEFT JOIN are then filtered out in the Merge function, with only the AlbumUID being collected.

This patch still lacks the code to refresh the Card's album list when a photo is added to an album using the context menu. Hit the reload icon or reload the page to reflect the updates.

Acceptance Criteria:

• [ ] Features and enhancements are fully implemented so that they can be released at any time without additional work
• [ ] Automated unit and/or acceptance tests have been added to ensure the changes work as expected and to reduce repetitive manual work
• [ ] User interface changes are fully responsive and have been tested on all major browsers and various devices
• [ ] Database-related changes are compatible with SQLite and MariaDB
• [ ] Translations have been / will be updated (specify if needed)
• [ ] Documentation has been / will be updated (specify if needed)
• [ ] Contributor License Agreement (CLA) has been signed

[graciousgrey]

Thank you very much for your efforts, we will look into this as soon as our time permits. I'm not sure if the card is the right place for it though. We have several requests from people who want different information in the card view. This is not a quick win as it impacts performance and requires additional settings. We have thought about adding the album list to the Details tab of the edit dialog. Ideally, it could then also have the function to open the album from there, add the photo to more albums, or remove the photo from one of the albums. I suspect it will be difficult to accomplish this from the card.

[mmaravillo]

The patch tries to address the need to conveniently see which album a photo is already in, while browsing through the search results.

I'm concerned with performance too that's why we pre-load the albumTitles dictionary. Then each photo will just lookup for the album Title from the dictionary without making additional calls to the backend API.

Perhaps we can add toggle options in the user settings so the user can choose what information appears on the card. For example, personally I prefer seeing the album list than the image/video dimensions and size. :)

[dror3go]

Seems like a weird location to put such information in. What if a photo belongs to many albums, or to album/s with a long title?

[dvpfig]

Seems like a weird location to put such information in. What if a photo belongs to many albums, or to album/s with a long title?

For long titles or many albums, there could be just a simple cut and a 3-dot "..." would show up to indicate that there is more.

[dvpfig]

Perhaps we can add toggle options in the user settings so the user can choose what information appears on the card. For example, personally I prefer seeing the album list than the image/video dimensions and size. :)

The card view is one of the more interesting views of PhotoPrism and could be used to give tailored information depending on the user preferences. I'd love to have this option in settings to toggle which info is shown.

I personally would prefer to keep the location (as it is now) rather than the albums, but I see a benefit in adding control which 3 items to show: in addition to the current time, file format, location, adding also optional to replace some of these with the labels, the persons recognized, the albums, or the aperture/exposure/iso.

However, this is a complex feature to implement, so chances are low to get it done, but adding just the albums in the card view to address Issue #373 is kind of limited IMO.

[lastzero]

Unfortunately, we cannot merge these changes at this time due to the following considerations:

(a) Using a left join may significantly increase the number of result rows, leading to count/offset issues (as it is currently implemented) as well as performance/scalability problems.

(b) An alternative could be to query all album UIDs as comma-separated values in a single field, e.g. using GROUP_CONCAT. It needs to be figured out how this affects performance and whether it works with other DBMSs like SQLite.

(c) Then, of course, the album names must be resolved correctly at all times on the client side and should not be outdated, e.g. when other users edit them on a different computer. Otherwise we might get bug reports for this.

(d) Last but not least, this has become more difficult with the new multi-user support, as only albums that the current user has access to should be visible. While I might be able to find a solution for this if I have some time to think about it (i.e. not while I'm working on 10 other issues at the same time), this will probably prevent external developers from contributing a solution that is ready to merge.

[lastzero]

Ultimately, the only viable solution might be to cache the content of all albums in the backend and dynamically add it to the search results with UID and title when needed, so that the information is always up-to-date and can be displayed directly.

[lastzero]

@mmaravillo There's still a lot to do before we could release it, and unfortunately we haven't received any feedback on our comments yet, so I'm closing this PR for now. Thank you very much for your contribution! :)