Unable to persist ExApp settings

đź’» Development
1

I’m in the process of getting my app ready for release, but I’m unable to get settings working. I’m making an ExApp in Python using nc_py_api and as far as I can see I’m following the example apps and documentation.

The problem is that any change made in the settings form does not persist. If I click another menu item and then back the displayed settings will be back to the configured defaults, and when I try to read from appconfig or preferences the returned values are always None.

Is there anyone that has this working? My NC instance is running v32.0.8 and I’ve tried all combinations of admin/personal appconfig/preferences and ai_integration_team/declarative_settings. When I change something in my settings form I see a perfectly valid Post made with a 200 OK response and the intended changed value.

    SettingsField(
        id="auto_analyze",
        title="AI Analysis",
        type=SettingsFieldType.CHECKBOX,
        default=SETTINGS_DEFAULTS["auto_analyze"],
        label="Enable AI-powered image analysis",
    ),


https://nc_server/ocs/v2.php/settings/api/declarative/value
[HTTP/1.1 200 OK 48ms]

app	“tagger”
fieldId	“auto_analyze”
formId	“settings”
value	1

auto_analyze_config = await nc.appconfig_ex.get_value(“auto_analyze”)

… returns “None”. Form registration works fine, it becomes visible and POSTs are made to the OCS API when I change values.

I’m at a bit of a loss here, any help appreciated.

2

Checking the database directly shows no trace of any persisted settings in either oc_appconfig_ex or oc_preferences_ex. The settings form itself is as expected in oc_ex_settings_forms. There are no errors in the Nextcloud logs - and as shown above the POST to the settings/api endpoint returns 200 OK.

3

I’m wondering if this might be an AppAPI error. I’ve found that SetValueListener.php::handle() finds a settings form null-value and returns silently. This, I think, in the listener method meant to get the changed values in a settings form and persist to appconfig/preferences.

            $settingsForm = $this->service->getForm($event->getApp(), $event->getFormId()); 
            if ($settingsForm === null) {                                                   
                    return;

I’ve added some debug output to this method and found that:

$appId: “tagger”,
$formId: “settings”,
$fieldId”: “debug_logging”,

This is interesting because the id of my settings form as configured in the app is “tagger_settings”, not “settings”.

4

Yeah. It’s the lookup in UI/SettingsService.php::getForm() that’s failing. It checks that both appId and formId match and when I run my code they … don’t:

“current_appid”: “tagger”,
“current_formid”: “tagger_settings”,
“looking_for_appid”: “tagger”,
“looking_for_formid”: “settings”,

current_formid is what’s stored in the database and looking_for_formid is the parameter that comes to getForm from SetValueListener::handle() which is the callback gotten when I change settings in the UI.

”tagger_settings” is correctly stored in the database, so it seems to be an issue with the Event passed on to the AppAPI listener for settings-changes.

edit: Of course - this is from the POST coming from the rendered UI settings page that I listed in the first post:

{“app”:“tagger”,“formId”:“settings”,“fieldId”:“debug_logging”,“value”:0}

So since the UI has rendered with “settings” as formId there will never be any changes made since no such settings formId has been registered.

I don’t think I can affect this, right? I call nc.ui.settings.register_form() with my form which has formId=tagger_settings and I can retrieve it with nc.ui.settings.get_entry(“tagger_settings”) and I don’t see anywhere I might be able to confuse the rendering of the form to have a different POST link.

… will look at the python lib too now.

5

Alright I’ve “solved” it.

Not working: Registering a settings form with id “appname_settings”
Working: Registering a settings form with id “settings_appname”

I can’t say whether this is by design or not, but it’s far from obvious that what you get is just a silent failure to persist any settings whatsoever from your ExApp :slight_smile:

It might need to be spelled out clearly somewhere here:

edit: At first I thought this would result in both formIds (stored and POSTed) becoming just “settings” but it’s actually even more interesting - both became “settings_tagger”. As to why “tagger_” gets lost if the ID starts with that would be the actual bug I guess.