Lightroom: Make collection context flags work globally for smart collections

[FeedbackCommunityMember]

It would be nice if collection specific flags could still work as criteria for global smart collections. This way, for example, the reject flag could be used to find rejects more easily.

[Mark Sirota]

So if a photo was rejected in Collection A and picked in Collection B, would it match a Smart Collection looking for rejects? Or would your Smart Collection rules say "rejected in Collection A" rather than just "rejected"?

[FeedbackCommunityMember]

The search criteria are still collection specific. We have criteria for "flags" = deleted ANDed with "collection name" is|is not|starts with "fnord".

Since we can stack the criteria as single arguments, we can easily make a smart collection that finds images deleted in any collection, and not a pick in any collection.

But, only if the criteria for flags and collections actually worked.

[Victoria Bampton LR Queen]

As of the Lightroom 4 beta, flags are now global. Read more about the beta here: http://blogs.adobe.com/lightroomjourn...

[Jeffrey Tranberry]

Per Victoria, As of the Lightroom 4 beta, flags are now global. Read more about the beta here:

http://feedback.photoshop.com/photosh...

[FeedbackCommunityMember]

Jeff/Victoria,

I would not mark this as "Implemented." The new global flag behavior is a major step backwards (for those who understand the old, much more powerful local behavior).

This topic is also essentially a duplicate/alternate posting of http://feedback.photoshop.com/photosh...

Sorry to be late to the party. BUT, this "new" global flag behavior is REALLY screwing us (and other colleagues and our workshop students) up.

We have many collections that contain Client Proofing selections via the Picked/rejected flags. They often contain overlapping images. One client might want to order Image123 (so click "Select"), but the next client may not (so click "Reject"). Similarly, their "maybe's" are left unflagged.

With LR4 we can no longer allow this proofing (without a huge hassle of maintaining separate, little catalogs for each client/job/interaction/output type). Seems like a big step backwards.

Additionally, all the selection criteria we have in LR3 up until this point is wiped out when "upgrading" to LR4. This seems like DATA LOSS, which we'd consider to be a bug.

(Similarly, we have collections that contain output jobs that use Local Status selections (and ordering) for what was/wasn't included. Examples include various Calendars, Books, and even Gallery Shows. )

Pretty, pretty please can you make local vs global flag behavior a simple Preference? (if local was confusing folks, then global could even be the default).

Please don't go the way Apple seems to be heading, in "dumbing down" your products, and create a Lowest Common Denominator situation.

[Rikk-Flohr]

This thread was marked implemented because a change was asked for and it was implemented. You are asking for dual behavior now and have already created a separate thread with your request. That is the place to marshall support and see if the following can be built to consider it.

For many, this made workflow much easier and was a positive step forward.

For others, it is not satisfactory either way or they cannot decide which way works best.

For some, such as yourself it was a step backwards.

Perhaps a different solution, rather than restoring old functionality, would better suit a larger number of people?

[Victoria Bampton LR Queen]

Chris, I'm sorry to disappoint you, but they're not likely to come back.

It wasn't just an issue of dumbing down, although it's had a minimal impact because very few people understood it. During the whole of the beta period, I only remember one thread on the subject, and it wasn't that long.

Picks/Rejects have become a primary method of refining image sets since it was originally implemented, and LR's local flags ruled out any possibility of cross-program compatibility. With them now globalized, future compatibility with other software such as Bridge, Photo Mechanic, Photosmith, etc., becomes a possibility.

The good news is it's not a data loss situation. If you right-click on any collection that previously had local flags, you'll be able to select them again, and use another rating system.

I know it's tough to have to change your workflow. Rather than adding to the collection and then flagging, you could flag in the folder, and then save their picks and their maybes as collections, before resetting the folder flags ready for the next person. No need to go into separate catalogs.

[FeedbackCommunityMember]

Oddly enough, the fact that my request was implemented by making collection-specific flags global has obviated my need for smart collection criteria that can use these flags.

I hate to add fuel to this fire, but I would probably have preferred just expanding the notion of the criteria to be "test for [pick | deleted] flag is true for photo in [any | selected] collection". That is, make the smart collection criteria and logic smarter, but leave the flag behaviour alone.

I don't really have a workflow that depends on flags being local, but it does seem like a scorched earth technique to change it in this manner. The net result is that I probably will not even use picks any more.

That being said, I often ended up doing my initial X/P culling in the handy Previous Import library bookmark view, which was often a mistake. I guess I can't make that mistake now.