Add batch editing #271

[vidaren]

This PR should solve issue #271 . – except editing of labels.
This PR implements batch editing: Editing of multiple properties for multiple photos in the details page in one operation:

• Make the changes to properties on one of the photos
• Click/Press and hold the APPLY or DONE button until a confirmation dialog appears
  The long-press method was chosen because it requires no UI for small devices.

Acceptance Criteria:

• Features and enhancements must be fully implemented so that they can be released at any time without additional work
• Automated unit and/or acceptance tests are mandatory to ensure the changes work as expected and to reduce repetitive manual work
• Frontend components must be responsive to work and look properly on phones, tablets, and desktop computers; you must have tested them on all major browsers and different devices
• Documentation and translation updates should be provided if needed
• In case you submit database-related changes, they must be tested and compatible with SQLite 3 and MariaDB 10.5.12+

Tested on MariaDB only, but I believe GORM will handle the changes for SQLite too.

[CLAassistant]

All committers have signed the CLA.

[graciousgrey]

Thank you very much for your contribution! We look forward to working with you on the batch edit feature once the recently merged pull requests have been successfully released :)

It might not be ideal to reuse the existing edit dialog. Instead we had planned to add a separate batch edit dialog to avoid confusion.

The following use cases will likely require additional consideration:

(a) Editing the date of a photo.

Suppose a user selects two photos that currently have the following date set:

• Photo 1 day:01 month:08 year:2022
• Photo 2 day:05 month:07 year:2021

Therefore, he opens the edit dialog of photo 1 and changes day:01 to day:03 and year:2022 to year:2020 and long clicks Apply to apply the changes to all photos. Now the user expects both photos to have the following date: day:03 month:08 year:2020. Instead, he gets the following result:

• Photo 1 day:03 month:08 year:2020
• Photo 2 day:03 month:07 year:2020

(b) Adding keywords to photos

Suppose a user selects two photos that currently contain the following keywords:

• Photo 1 keywords: banana, yellow
• Photo 2 keywords: apple, red

Therefore, he opens the edit dialog of photo 1 and changes the keywords: banana, yellow to keywords: banana, yellow, fruit and long clicks Apply to apply the changes to all photos. As a user I would now expect the following

• Photo 1 keywords: banana, yellow, fruit
• Photo 2 keywords: apple, red, fruit

Instead I get

• Photo 1 Keywords: banana, yellow, fruit
• photo 2 keywords: banana, yellow, fruit

An additional benefit of having a separate Batch Edit dialog is that users can always see exactly which changes are applied to their images. This is not the case with the current implementation, as the user has to remember exactly which fields he just changed and which were already set before.

Also, in a separate batch edit dialog we can add additional fields that are not present in the normal edit dialog, for example, a field to add labels and a field to remove labels.

[vidaren]

@graciousgrey You raise some good points in (a) and (b). My implementation is a bit crude that way, not smart at all, only taking the new field values and storing them on all selected photos. It was written for my personal need, adding coordinates and country to groups of photos that don't have them, which it does well. I then included the rest of the fields on the Details page for completeness, without thinking much about the use cases you mention.

Removing date and keywords from the fields that can be batch-edited makes sense, perhaps: Just don't batch-save the changes made (not the best UX, I know.) At least the date does not need batch-editing, or editing at all, most of the time.

[sclu1034]

The way I usually see bulk editing implemented is that in the edit dialog, every field gets additional, virtual values <keep> and <clear> (or variations thereof). And the logic is

• all fields in the bulk edit dialog start with a default value of <keep>
  • unless you have all data for all entries loaded, in which case you can also differentiate between:
    • if every entry has the same value in a field, pre-fill the field in the dialog with that value
    • otherwise pre-fill with <keep>
• on submit, for every dialog field
  • if the value is <keep>, each entry's individual value in that field is kept unchanged
  • if the value is <clear>, apply the default value for that field on every entry
  • otherwise apply the given value to every entry

And for array-like fields (like keywords and labels), bulk edit dialogs usually have two input fields as graciousgrey mentioned: One "add values" and one "remove values". So with example (b) from above, the logic would be

Add keywords: fruit
Remove keywords: yellow, green

Before

• Photo 1 keywords: banana, yellow
• Photo 2 keywords: apple, red

After

• Photo 1 keywords: banana, fruit
• Photo 2 keywords: apple, red, fruit

Other additional fields that a dedicated bulk edit dialog could have, would be things from the last tab (Orientation, Panorama, Favorite, etc.).
And while the "long press opens confirmation" flow works, a proper "apply to all" button in that dedicated dialog would be a lot more intuitive. In my experience, people don't just peruse whole documentation pages to discover something like "this one particular button actually has additional functionality if you press and hold".