Skip to content
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

Closed
scruffynerf opened this issue Nov 9, 2023 · 4 comments
Closed

[Bug Report] New plugin settings bugs in develop #4273

scruffynerf opened this issue Nov 9, 2023 · 4 comments
Labels
bug report Bug reports that are not yet verified

Comments

@scruffynerf
Copy link

scruffynerf commented Nov 9, 2023

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)

@scruffynerf scruffynerf added the bug report Bug reports that are not yet verified label Nov 9, 2023
@scruffynerf
Copy link
Author

oh, and xyz (strings) are the same issue, nonexistent until set.

@scruffynerf
Copy link
Author

scruffynerf commented Nov 9, 2023

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)
but really, if the plugin is enabled upon loading automatically, shouldn't the key itself be valid then and there?

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).
OR
disable plugins by default, add to disabled list, add to settings as well?

@scruffynerf
Copy link
Author

scruffynerf commented Nov 9, 2023

ok here's working code to handle the above without any server changes being made:

def get_settings():
    # plugincodename is already a global str holding the plugin's name (same as name of .yml)
    current_settings = {}
    # I'm using a python import for the defaults, but you could hard code a dict here.
    defaults = DEFAULT_SETTINGS
    # do we even have a key yet?
    # if @stg-annon adjusts stashapi to handle the keyless plugin, this can be removed
    # right now, it fails to read any existing values, no key found, and so you can't set a keyless plugin
    plugin_config = stash._callGraphQL("query { configuration { plugins } }")
    pluginlist = plugin_config["configuration"]["plugins"]
    if plugincodename not in pluginlist:
        #no plugin settings at all, no key found
        query = """ mutation ConfigurePlugin($plugin_id: ID!, $input: Map!) { configurePlugin(plugin_id: $plugin_id, input: $input) }"""
        stash._callGraphQL(query, {"plugin_id": plugincodename, "input": defaults })
        log.debug(f"{plugincodename} not found in Settings, setting all defaults")
        return defaults
    # the plugin key was found, but some settings might not exist, loop thru the defaults and set if not found
    current_settings = stash.find_plugin_config(plugincodename)
    update = False
    for key, value in defaults.items():
        if key not in current_settings:
           log.debug(f"{plugincodename} setting {key} not found in Settings, setting to default value of {value}")
           current_settings[key] = value
           update = True
    if update:
        stash.configure_plugin(plugincodename, current_settings)
    return current_settings

@scruffynerf
Copy link
Author

scruffynerf commented Nov 9, 2023

thanks to @stg-annon 's stash api work as of 5125c32
the above code is now entirely replaced by:

settings = stash.find_plugin_config(plugin_name, default_settings)

Making life easier for all (python) plugin devs in future.

Calling this solved, for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Bug reports that are not yet verified
Projects
None yet
Development

No branches or pull requests

1 participant