(imported topic written by SystemAdmin)
Pretty, Pretty, Pretty Please.
I can not tell you how much time this would save. We can define the logic once and not have to update multiple fixlets, tasks, dynamic groups, etc. Oh the agony.
john
(imported comment written by BenKus)
Here is our issue with this request…
What if we allow this… and then you (or someone else without the history) change one property and it cascades to other properties and other actions that were targeted by these properties and then you have all sorts of problems with actions running/not running (servers rebooting, applications deploying randomly, pandemonium!)…
This is a big nightmare and it keeps us from considering these “references” inside of relevance.
Ben
(imported comment written by SystemAdmin)
Ben,
Real quick thought - How about locking “locking” the Retrieved Property when it is used or referenced elsewhere. This may require the ability to enable / disable items (Dynamic Groups / Fixlets / Tasks, etc). So it would require a new feature for the new feature. Without the Enable / Disable we would have to export all the dependent items, delete the items, modify the Retrieved Property Relevance and then import the dependent items again.
Or give us version control. If each revision is stored, then the items could reference a revision and that would prevent the pandemonium.
We’ll be the guinea pigs. I can’t imagine a bigger time saver for BES admins - well, maybe auto updating version controlled baselines for MS patches but beggars can’t be choosers. We could create tons of pre-canned relevance and reuse them at will. Yippie!
(imported comment written by currier59)
One thought is to be able to choose the RP from a drop down or something and have the “current” relevance plop into the place you were when editing/creating task/fixlet/group/etc… But also add a marker which notes the RP just used. The marker (like a comment) is not used for relevance but as a way to search for all tasks/fixlets/groups/etc… which are using this property (only a reference no actual script changing). The Console could have a reserverd property which lists all properties currently being referenced by a task/fixlet/group/etc… with a drill down to list the individual task/fixlet/group/etc… using the property.
So first if you are going to change a property you can see what you are affecting.
Second, if the property is changed give the operator the ability to select the tasks/fixlets/groups/etc… to update or not.
Last, after the operator changes the property, selects what to update, if there are any tasks/fixlets/groups/etc… the operator left as is, the property marker is removed (or tagged as out of sync automatically) and the tasks/fixlets/groups/etc… are no longer listed by the BigFix Reserved Property. And the content is simply left as it was using the same relevance originally used.
Just a thought for a compromised solution for both sides of the argument… ;-))
(imported comment written by SystemAdmin)
This sounds similar to the version control we proposed. The only drawback we see is on your last point. Unintentional updates of markers is BigFix’s fear while orphaned markers are one of our fears. The orphaned markers in your example would have to be tagged as out of sync or else we’d have chaos.
We’d really like some type of version control where we could see how many version we have, what the differences are and where they are all used. Version control would satisfy a whole bunch of process control issues as well, sort of they way actions can not be modified once issued and a new action is required. That’s version control on the simpliest level but it works.
But we are open to compromise especially if it allows use of Retrieved Properties in Relevance 
(imported comment written by SystemAdmin)
Version control is high on our wish list too. Managing and maintaining large amounts of custom content across many tasks/fixlets/baselines is tedious.
A good first step would be increased visibility from a task/fixlet perspective. Where all do instances of it live? What baselines is it part of? An Instance or Version management tab would be a welcomed addition for tasks and fixlets.