setClientSettings may break client behavior when assigning group (memberof)

[yoya93]

Hi there!
First of all, thanks for this library — it's been very helpful in automating our UrBackup workflows

I'm running into an issue when using setClientSettings() to assign a client to a group by setting the memberof key

await server.setClientSettings({ clientName: 'Client_XYZ', key: 'memberof', newValue: a094, });

This correctly updates the group assignment, but after this change, the client starts behaving incorrectly.
The group is updated successfully — as you can see in the image attached — but it ends up breaking other settings such as internet_authkey and archive

After debugging, I noticed that setClientSettings() fetches all client settings via getClientSettings()

After comparing with what the UI does when assigning a client to a group, I found that the frontend sends a much more complete payload, even when only changing the group. For example, it sends something like:

sa=clientsettings_save &t_clientid=63 &internet_authkey=O111111111118 &internet_authkey.use=2 &archive= &archive.use=2 &memberof=10 &ses=JmvXm36111111BHEBkLix9FBm &lang=en

Let me know if I can help test or provide more details!

Thanks again for the awesome work on this tool

[yoya93]

Hi! 👋
I'd like to suggest adding a new method called setClientGroup that mirrors how the web UI (miui) updates a client's group using minimal payload. This helps avoid unintentionally overwriting unrelated settings.

Problem
Currently, when using setClientSettings, it retrieves all settings and sends them back in the update payload. This can unintentionally overwrite values like internet_authkey, archive, or other fields if they are not explicitly preserved.

When the UI assigns a client to a group, the payload looks like this:

sa=clientsettings_save t_clientid=63 memberof=10

This minimal approach avoids side effects.

Proposed Solution
Here's the method I implemented to update only the group (memberof) without touching other settings:

`async setClientGroup({ clientId, clientName, groupId }) {
if (
(typeof clientId === "undefined" && typeof clientName === "undefined") ||
typeof groupId === "undefined"
) {
throw new Error(this.#messages.missingParameters);
}

let operationStatus = false;

if (clientName === "") return operationStatus;

const login = await this.#login();
if (!login) throw new Error(this.#messages.failedLoginUnknown);

const clientSettings = await this.getClientSettings(
  typeof clientId === "undefined" ? { clientName } : { clientId }
);

if (!Array.isArray(clientSettings) || clientSettings.length === 0) {
  throw new Error(this.#messages.missingValues);
}

const { clientid } = clientSettings[0];

const payload = {
  sa: "clientsettings_save",
  t_clientid: clientid,
  memberof: groupId,
};

const saveSettingsResponse = await this.#fetchJson("settings", payload);

if (typeof saveSettingsResponse?.saved_ok === "boolean") {
  operationStatus = saveSettingsResponse.saved_ok === true;
} else {
  throw new Error(this.#messages.missingValues);
}

return operationStatus;

}`

I’d be happy to open a PR if this addition aligns with your roadmap. Let me know what you think.

Thanks for your great work on this project!

[bartmichu]

Wow, this is fantastic - thank you so much for investigating the bug and providing all the details.

I really like your idea of adding a new method - not just as a workaround, but as a generally useful feature that fits perfectly within the overall API design.

I’d be more than happy to merge your changes if you could open a PR. Thanks again!

[bartmichu]

@yoya93 I’ve just implemented the getClientGroup() and setClientGroup() methods. Thanks for your help.