Part of the Custom Options project.

Some care is needed for this. Some custom options are “condition” values, like a toggle or dropdown. Others are “property” values, like color. Still others seem like they could be both.

Additionally, since these values can only be edited while WeakAurasOptions is open, we can probably introduce them with relatively minimal impact - instead of looking up the values each time, we can directly insert them into the generated functions.

Additionally, we may need to decide what happens if an author creates duplicate keys. I have a changeset that will warm the author about duplicated keys, but if we also use them ourselves then we need to be more careful than that, I think.

@InfusOnWoW, conditions are your baby. Do you have any thoughts to contribute?

Yes. This would be useful.

As to implementation, you can probably figure it out mostly by how global conditions are added, since those are also not trigger specifc.

The available global conditions are returned by GetGlobalConditions, which is used in 3 places:

• createConditionTemplates creates the option selection.
  You would need to add a mapping from various options to whatever type of condition check should be allowed on them.

• RegisterForGlobalConditions ensures that the conditons are evaluated on the right events (which you don't need to care about, since any conditions are always checked on show)

• ConstructConditionFunction actually creates the condition function, the actual test is created in CreateTestForCondition, so if you want to check at function creation you would need to add that into that function. The conditionTemplate is a part of what GetGlobalConditions/GetConditions returned.

I htink the condition function is always regenerated on a Add call, so it should automatically update on changes to the author options.