This function would be also very useful for us. So one more vote from us.
Gira Giersiepen GmbH & Co. KG
Some of our usage of the Tag function
It makes sense to allow Tags changes on a locked item because Tags are not revision controlled.
Locking should have no impact on properties that are not revision controlled: locations, tags …
I support your Ideal, Jeffrey, but to keep it according to the rule above, I'd like to be able to configure fields as excluded from the revision control system and so from the lock.
Fields without revision control & lock would be an alternative to tags to define after-facts filters a more structured way.
As use case, I'll refer you to Tim's Post (number 3)
"Teams want to modify tags after approval to then create custom filters based on the tags. E.g. you might tag 'internal' vs 'customer' for visibility on what requirements you are willing to share or tag 'datasheet' for results you have chosen to publish."
This would be a perfect match for fields w/o version control & lock: he knows upfront that a visibility field will be needed but he wants to lock his item before he has the visibility information.
I don't like the tags because anybody can create whatever tag so it needs a lot of discipline not to become a mess. Fields w/o version control & lock address that concern.
I have also interest in fields w/o version control because I'd like to run automations that would populate some fields with information from related items (several levels below). This to build some Items' embedded summaries. Today, we create mini-reports to provide this overview but those need to be triggered manually each time. Automation is today disregarded because this would generate uncontrolled number of Item versions.
HEADQUARTERS|135 SW Taylor Suite 200, Portland, Oregon, 97204