Custom options's "option group" default data
mrbuds opened this issue · 2 comments
Is your feature request related to a problem? Please describe.
When updating an aura, default behavior for custom option data is to keep user data.
If an aura have a new custom option of the type "option group", for example a spell list, after an update with custom option update disable, that list will be empty (if i understand correctly), because there is no "default" for this field.
Describe the solution you'd like
I don't know exactly what's the best way to solve this.
Maybe auto-import data for new option group fields ?
Describe alternatives you've considered
Something in author mode to mark current data as default, so when user push the reset button it doesn't empty the list filled by author.
Additional context
For https://wago.io/BFADungeonTargetedSpells I had a list of spellids, and options for each spells set in a custom function on init.
Updates on custom options from last release let me move this list to custom option UI, but i think/fear most user won't update custom option data when updating aura and will get an empty list of spells.
Well, your update context is a use case for #1399...
Additionally, proper support for default data in option arrays is a tall order. It's why custom options originally didn't ship with group support. There are a few snags here:
There's a difference between resetting an array, and resetting an array's entries. Currently we only support resetting the array as a whole. If we support resetting an array entry, then the only non-thorny solution would be to support resetting to the option's default values, instead of author-supplied custom config.
Resetting entries that have been re-ordered is nontrivial. Consider an array that has default entries A, B, which do not have the same default values. We have several options on what happens when a user clicks "reset entry to defaults":
- Reset entries to the empty state ∅.
- This is equivalent to deleting and then adding a new one today. We lose data, but then the user did ask for that data to be lost, and an "undo" button (which we want for other reasons too) would fix the data loss problem.
- Reset entries based on index: If [A, B] is re-ordered to [B, A], and B is reset, we get [A, A]
- What happens if entry B is deleted, and then a new entry is created? Do we get B? Do we get an "empty" entry ∅? What if the user adds more entries than the author originally supplied? I suppose we would give them ∅ for each new one.
- Reset entries to their original index: If [A, B] is re-ordered to [B, A], and B is reset, we get [A, B]
- This is weird and I don't like it. Also it doesn't handle new entries at all, since they'd have no default.
- Add a unique ID to each entry, so that resetting A' in [B, A'] gives you [B, A]:
- Again, this doesn't handle new entries, and we get the deletion problem again. If a user deletes B and creates a new entry afterwards, should they get B, or should this new entry not be attached to B at all.
- What happens when an aura with [A, B] is updated by the user to [A, B, U], and then the author updates and adds [A, B, C]?
The correct solution to this minefield is, in my opinion, to delegate it to the authors via migrations. That idea was rejected, so we won't be solving this fully unless someone comes up with a non-insane strategy, or we change our mind and decide to implement author migrations.
In the meantime, though, resetting an entry to the empty state defined in Author Mode does make sense, so I will add a button to do that in the entry selector.