-
-
Notifications
You must be signed in to change notification settings - Fork 794
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug Report] New plugin settings bugs in develop #4273
Comments
oh, and xyz (strings) are the same issue, nonexistent until set. |
Bug 3: if the plugin is enabled (like upon reloading plugins), but nothing is edited at all, the settings key is still non-existent, leading to a current error in stashapi handling of looking for a key and getting no results (which @stg-annon can address) If I disable the plugin, it now shows up in disabled in config.yml, but still has no settings in config.yml Right now, a freshly loaded plugin is enabled, with mostly nonexistant values, and no way to even determine it's enabled, since it's not in disabled, and has no key to load settings. Sigh, I'm wrong above in error 1 too... Even the Boolean is nonexistent, I must have toggled it without realizing it on first loading it. So the Problem is: new plugin loads: No plugin key, no settings at all, Then edit any setting, and the key appears, with that setting, but not the other settings. Ideally: if enabled, create plugin setting by name, and populate default empty values (false, 0, empty string). |
ok here's working code to handle the above without any server changes being made:
|
thanks to @stg-annon 's stash api work as of 5125c32
Making life easier for all (python) plugin devs in future. Calling this solved, for now. |
related to #4143
the new Plugin Settings:
bug 1:
while a boolean gets a return of false automatically, even if never setting (ie on installing the plugin),
numeric settings default 0, but return nothing unless set first. (so it's literally not listed as a setting, despite the UI saying 0)
Since you can't later set it to 'nothing', it's also impossible to reset back to that 'initial state' after changing it.
I was trying to create a 'default' settings, and in the case of the example Foo/Bar/xyz settings, if Bar doesn't exist, and the results are just Foo, I could do this, but if I edit Bar from 0 and end go back to zero, now the settings won't match the 'untouched' initial state, meaning I'd have to handle both cases (and that's just for one variable, it gets worse for multiple)
Editing config.yml and deleting the plugin settings, restarting stash, will restore it to 'untouched' yet Bar will still say 0, even though the value is now non-existent again.
Fix: either
a) if Number is unset, return 0 in query,
OR
b) fix UI to reflect no value?
The 'no value' settings are a bit annoying, but writing a
get_settings
function, you could always add defaults, and it would be much nicer if the UI and the query results matched, since once the UI is 'touched', you can't get back to the untouched state without editing config.yml, so a lot of setup code will be needed only until the user edits a setting once, which might be cleaner if the settings just defaulted to false, 0, and empty string if not set.bug 2 (minor change in schema):
The initial commit documentation said the filter is Includes, but turned into Include, and the schema has that. Mostly to note it did change, if someone looks at that PR for help (as I did)
Kudos to @stg-annon who wrote code for stashapi correctly (which I discovered only after I reinvented the wheel and got it wrong)
The text was updated successfully, but these errors were encountered: