Add support for extensions that need multiple options pages with independent options

[tdulcet]

The Thunderbird CloudFile/FileLink API needs to have multiple "management" pages for configuring each account the user adds. Each page is the same, but they need to have independent options that are saved to and loaded from storage.

I am aware that part of this can be done with the AutomaticSettings.Trigger.addCustomLoadOverride() and AutomaticSettings.Trigger.addCustomSaveOverride() functions, but it requires a lot of nasty hacks which eliminate many of the benefits of this library. For reference, here is the recommend way to get and set options in these "management" pages without this library. It would also be helpful if the addCustomLoadOverride() function accepted an option group, like the addCustomSaveOverride() function does, instead of having to call it for every individual option.

For example, I would like to use this library to create a FileLink provider for Firefox Send, the end-to-end encrypted file sharing service originally created by Mozilla, which is now called just Send after it was discontinued by Mozilla last year and now maintained by the community.

Here is an example of what these "management" pages look like in Thunderbird's UI:

It is a mockup of the proposed extension with one account. Users can select one of their accounts on the right and then set the options on the left. Everything on the top and left is Thunderbird's UI, while the rest starting with "📤 Thunderbird Send" is the options page.

[rugk]

Yeah, that'd certainly be a nice feature. However, it's really a lot of work, I guess, and
Remember this is just a small “tiny” library here that is intended to ease the settings creation.

[tdulcet]

However, it's really a lot of work, I guess

I do not think it would be a lot of work, at least not as far as LoC. As I said above, I was able to get it to work using just addCustomLoadOverride() and addCustomSaveOverride(), but it is not very pretty (JSDoc comments removed for brevity):

let accountId = null;

function get(param) {
	// Use the existing or the default option
	return AutomaticSettings.Trigger.overrideContinue(param.optionValues.account?.[accountId]?.[param.option] || param.optionValue);
}

async function set(param) {
	// Get the existing + default options
	let account = await AddonSettings.get(param.option);
	// Remove the default options
	account = Object.entries(account).reduce((a, [k, v]) => (v === Object(v) ? (a[k] = v, a) : a), {});
	// Set the new options
	account[accountId] = param.optionValue;

	return AutomaticSettings.Trigger.overrideContinue(account);
}

export function registerTrigger() {
	accountId = new URL(location.href).searchParams.get("accountId");

	AutomaticSettings.Trigger.addCustomLoadOverride("service", get);
	AutomaticSettings.Trigger.addCustomLoadOverride("downloads", get);
	AutomaticSettings.Trigger.addCustomLoadOverride("time", get);
	AutomaticSettings.Trigger.addCustomLoadOverride("size", get);

	AutomaticSettings.Trigger.addCustomSaveOverride("account", set);
}

It also is not scalable to more than one option group and this obviously disables the managed options feature. In addition, the reset button will reset all accounts, not just the selected account. See full example of the above code here.

[rugk]

Okay so, feel free to send a PR then. Maybe keeping the option groups working may a problem, but maybe I'm wrong there.
Though one needs to think how to enable/use this feature.

I don't consider this high-priority though, as said.

[tdulcet]

I think this feature would have lot of uses besides just the Thunderbird CloudFile/FileLink API, probably any extension that needs to support multiple accounts, particularly those using the identity API. However, I agree that the two issues blocking parts of Unicodify and the Awesome Emoji Picker are a higher priority.

The above code block should work well enough for my proposed extension for now, although it would of course be best if this feature were supported by the library for the many reasons noted above. I would definitely be interested to hear how you think we could best implement this feature...

I was thinking we could add a optional argument to the AutomaticSettings.setDefaultOptionProvider() function, which would eliminate the need for the above code block:

const accountId = new URL(location.href).searchParams.get("accountId");
AutomaticSettings.setDefaultOptionProvider(AddonSettings.getDefaultValue, accountId);

When the optional argument was provided, the library would just use another level of indirection when saving and loading the options to and from storage, so it would hopefully require very few changes to the library. Specifically, all the options and option groups would be saved in an object named the value of that argument:

{
	account1: {
		group1: { /* ... */ },
		group2: { /* ... */ },
		group3: { /* ... */ }
	},
	account2: {
		group1: { /* ... */ },
		group2: { /* ... */ },
		group3: { /* ... */ }
	},
	// ...
	accountn: {
		group1: { /* ... */ },
		group2: { /* ... */ },
		group3: { /* ... */ }
	}
}

Okay so, feel free to send a PR then.

I do not currently plan to create a PR for this feature, although if you have any interest, I am open to collaborating with you to implement the feature or even the proposed add-on. Otherwise, feel free to add the "help wanted" label.

[rugk]

Okay, though your API idea sounds good to me.
We could only avoid having to overwrite the default options provider by just using a special API like AutomaticSettings.setGlobalSettingsGroup or so.
Also, I guess the default options would be the same for each account, so duplicating that is likely not useful.