Protect photos from accidental modification

[frankdarwin]

It happened to me several times that I accidentally changed photos (people, date, rating, etc.) after I had finished editing them for some time and wanted to keep their current state as final.
This can happen if you don't pay attention when selecting the photos you want to make changes to and select more photos than intended.

When that happens, you usually don't notice it right away, but mostly by accident much later.
Then good advice is expensive and the work starts all over again.

That's why I came up with the idea to specifically protect photos from being changed in IMatch and to implement a function similar to read-only.
Since I can imagine that the same thing has already happened to others and will happen again and again, my suggestion meets with approval.

[Mario]

This would be quite complicated to implement. Consider dealing with things like mixed selections of "protected" and "non-protected" files, metadata re-import, Metadata Templates, all apps which work with metadata and lots more. Everything would need to change in order to implement this complex feature. And I have not even started thinking about this in detail.

I still regret adding the "protected files" feature (hiding files from View) years ago - because it caused to much additional work over the years.

I must say that I have never accidentally changed the metadata or other things about a file. At least not without noticing and then an Edit > Undo usually resolves things.

If you are in the habit to frequently selecting and changing the wrong things for the wrong file, maybe rethink your workflow and where and when you edit metadata or rename files or change date and time?

[PandDLong]

I have made accidental metadata changes a few times as well (my beginner bad-luck perhaps?).

I repurposed a tag and set the contents to 'LOCK' for files which I am done with and shouldn't need changes.  I conditionally display that tag in bright red on the metadata panels I typically use for making changes and have a notation in the top-left of many file window layouts as well.  Those provide me a reminder that I shouldn't be making changes to the file.

As an extra precaution, I have a data-driven category that checks for pending writeback on such files which alerts me that I made a mistake.  I always check it before I do a write back (which I only do occasionally) to make sure there aren't any accidental changes.  If there are, I can see which tags are pending write-back and do some form of correction or recovery before any writeback.   Setting the file as Read-Only is also a way to prevent accidental changes from being written to the file.

Not surprisingly, I haven't made any accidental changes since putting this in place.   (But it is good to know that I won't have an ugly surprise one day to see that a bunch of photos have the wrong data).


Ironically, I find the "protected files" feature a little annoying because I will accidentally click the icon and then I have to go look up the help on how to "unprotect" because I never remember.  So I support not making more "lock-out" features in the software.

Michael

[Mario]

Maybe I should add an option for protecting files that hides the icon etc. for users who don't need it.
I can tell also link this with telemetry and see how many users really use protected files. And if there is only a handful, I can remove the feature to simplify things...

[frankdarwin]

Hello Michael,
thanks for the tip!

Can you please let me know which tag you abused and how you entered the content of the tag into the layout?
Thank you.

[Mario]

You don't need to abuse a tag. You can use a label or dot or pin or flag or even a category form the same purpose.

[PandDLong]

Good point - there are many ways to set this up and fit it into your workflow.  Using a tag is not required.  iMatch has lots of options.

For me, I chose a tag so I could highlight the situation on my metadata panels - as per attached screenshot.    The tag I used is in the IPTC Extension group - 'Workflow Tag CV Id'. I am only sharing files with family and friends who only require and/or can only access the basic tags.  If you share more broadly, I think you need to make sure the tag you plan to use is unused by everyone with whom you share.   

I use a metadata template to populate the field - I have a template I run before doing a "I'm all done with these files" write-back.  The template does a few things for me and this is one of them (so it fits right into my workflow).   I could also enter it in a metadata panel but since I have a template I run anyway, I just added to that.

Michael

[axel.hennig]

I can tell also link this with telemetry and see how many users really use protected files. And if there is only a handful, I can remove the feature to simplify things...

Please don't do. I use the "protected files" feature and I really find it helpful/useful.

[Mario]

Please don't do. I use the "protected files" feature and I really find it helpful/useful.

This is always the question, right?

If only 5 or 10 users use a feature, should I continue to support it? Or should I reduce complexity in IMatch by removing it?
Some features are finished and don't cause additional work - which means I can just keep them in that state.

The protected files feature is much more troublesome. They need to be considered everywhere: File Windows, IMWS, endpoints, apps, even in IMatch Anywhere™ WebViewer and the new File Window Gallery layout.
This all means I need to mind this feature everywhere, make sure it works where needed, consider it when I create new apps or endpoints etc.

So, if only 5 or 10 users are using protected files, is it worth the time and effort?

[Damit]

I also would love to be able to "Lock" certain metadata or files from being changed.  Sometimes you have files that no longer need any work and you want to avoid making any unwanted changes. It seems others want this feature as well.  It is important to consider that just because you do not make this kind of error, this may not apply to all or even many of your users. Your workflow, knowledge, fastidiousness, etc may be different. You are also very sensitive to metadata changes due to what you do, and have more experience than most IMatch users. Please consider adding this feature.

[sinus]

Like Michael
I made for such images, what are finished and should not be altered, some special visual "effects". 

See attachement, the image in the middle has another color around the whole thumb (ahem, purple or so). This is made with a label. The same label is written at the bottom on the right (Info-zv-Master).

Further I have a "workflow-checker", this represent the green bar, just under the categories. IF this is completey green, this image is finished, else there are written some abbreviations like "STA" or so. 

At the top I have on the right a kind of pencil to give me a clue over the status of an image.

With bigger icons or other visual clues I could mark an image even more. Or/And, like Michael, add some visual stuff to the metadata-panel. 

But of course this all does not prevent from accidental changing some stuff.
I happend for me too, but very seldom. In the last, say 10 years, maybe 4-5 times. This is not enough for me to change something in my workflow.

If it is easy to add a kind of protection for Mario, then I would support it of course, else not. Even with some further protection, I am sure, humans will find a way to do some mistakes. 

[Damit]

Thank for your input Markus. I like the ideas you and Michael propose, though I do not understand them fully.

Setting the file as Read-Only is also a way to prevent accidental changes from being written to the file.

I guess this is really the best way to go.  Once you have finished with the file, make it read only.  You can always change it back.  I think what is being proposed is making certain metadata, like the file rating, read only.

[Mario]

The read-only shield reflects the read-only attribute in the File System.
Which is optional in Windows and may not be respected.

It does not prevent users from accidentally modifying metadata in the Metadata Panel, Keyword Panel, via @Keyword categories, the rating/label controls in File Windows, Metadata Templates, Favorites, Face Recognition.

IMatch is all about adding, updating and deleting metadata. I doubt many users have problems with accidentally modifying metadata - the FR has only one like so far. And there is always Edit menu > Undo.

If a user knows that she/he is prone to clicking the wrong things in File Windows or entering accidentally data in the MD / KW panels - all these panels can be hidden. Icons in the File Window can be hidden. The Categories Panel can be hidden. Which prevents accidental changes to metadata neatly.

A user can create a workspace without potentially dangerous panels and switch as needed.
Or configure IMatch to open databases  in read-only mode (Database menu) to disable all features that modify a database.

So many ways to do this already, no more features needed.
IMatch has enough features and options and switches as it is.

[Damit]

The read-only shield reflects the read-only attribute in the File System.
Which is optional in Windows and may not be respected.

It does not prevent users from accidentally modifying metadata in the Metadata Panel, Keyword Panel, via @Keyword categories, the rating/label controls in File Windows, Metadata Templates, Favorites, Face Recognition.

IMatch is all about adding, updating and deleting metadata. I doubt many users have problems with accidentally modifying metadata - the FR has only one like so far. And there is always Edit menu > Undo.

If a user knows that she/he is prone to clicking the wrong things in File Windows or entering accidentally data in the MD / KW panels - all these panels can be hidden. Icons in the File Window can be hidden. The Categories Panel can be hidden. Which prevents accidental changes to metadata neatly.

A user can create a workspace without potentially dangerous panels and switch as needed.
Or configure IMatch to open databases  in read-only mode (Database menu) to disable all features that modify a database.

So many ways to do this already, no more features needed.
IMatch has enough features and options and switches as it is.

Yes, it does!!!!

Thanks for pointing all that out, it may not be as apparent to newbies like me.