@Configuration Manager doesn't know who run the member freeze and why member was frozen.
The intention of this feature (when it was introduced long time ago) was to prevent users (newbies) from updating the member revisions. Freeze/Thaw permission is given only to specific users on sensitive files. So this permission should anyways be not available to all members, instead, only to some specific members. If this is followed, then it should not be a problem to figure out who run freeze.
Unfortunately there were many recommendation in the past that stated that you should e.g. run a freeze prior to each checkpoint operation (as the Checkpoint took so long, it was likely to be corrupted in larger projects) and thaw it afterwards.
Given the policy to checkpoint often, the group of user that can apply a checkpoint is rather large and therefore also the user that can and do perform a freeze/thaw.
Of course you can get around all this by creating a trigger that generates a label (containing the user an d the timecode) for each frozen member. But this is a huge waste of resources and slows down the system.
So IMHO your comment seems a weak reason fro dropping this valid an valuable idea.
BTW: a comparable feature for changed (shared-)sub-project configurations would be great as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.