Possibility to hide or remove a "newClient" button

[dmitrydvornichenko]

Is your feature request related to a problem? Please describe.
Hello team.
I have a task to deploy a tiny and cute frontend, which will distribute wg configs for users of our organization. I decided to use your package, because it is 100% suitable.
We use dedicated server as a wg endpoint (VyOS cluster on vrrp), so I don't need to create peers from UI. I am populating config.json by ansible task and launch wg-ui as docker image with pre-configured json. Users are authenticating with oauth2-proxy, which I'm launching from docker as well.
The system is working perfectly. The last task that I have is to remove "newClient" button from page.

I am not experienced in building applications or golang programming. I was able to edit Clients.svelte file and launch frontend, but making docker-image from this seems too hard for me.

Wireguard soon will be available not only on servers but on embedded devices, routers, appliances etc as well. I think, using your package just as an UI server for distributing configs (without managing wg) will be demanded by lots of people.

Describe the solution you'd like
Add a new flag "remove-newclient-button" to config, which will just remove the "newClient" button from page.

Describe alternatives you've considered
Add a flag "lock-config" which will remove the "newClient" button and remove "edit configuration" button to remove all possibilities for users to edit anything.

[spetzreborn]

I think there might be a way to accomplish this and get two extra beneficial functions.

If we are adding an API endpoint, something like /uisettings we can use that as a way to send startup options from the go binary to the compiled frontend. (or extend GetClients() to send additional information)

I see two uses when we want to remove the newClient button, the one that @dmitrydvornichenko describes and when the user has reached the limit configured by --max-number-client-config.
If the user has reached limit we might change the color of the button, or send an alert directly at the click of the button and not need to direct user to the NewClient.svelte.

Another use for this function to communicate to the front end i something not related to this issue, but to make "default config name" configurable from the back end.

An example of an stuct would be:

type UIsetting struct {
maxClients int
allowCreateConfig bool
defaultName string
}

[spetzreborn]

As a curious side note, why are you not letting your users create, name and delete their own configurations? Is it not good if the users can delete configs that have been exposed or no longer needed?

[dmitrydvornichenko]

@spetzreborn our users are call-center operators, whom we are transferring to a remote mode of work). No offending but for such kind of users, everything that is not needed, must be denied))
If you let them do what they want, they'll ruin your application) trust me)))

As for deletion, it is much easier to remove configs from json by script on termination of an employee.
Of course, if there is a dozen of people in the organization, self-service is OK, but we have about two hundreds)) I swear, those barbarians would break everything if I give them a chance)

By the way, I've read some manuals and solved my problems with binary building.
On Centos7, go-bindata-assetfs binary is situated in /root/go/bin/ and go build doesn't use it as a PATH by default.

So... the button can be easily removed in main.css:
.newClient.svelte-o5v00 {
float: right;
display:none
}

[suom1]

I see two uses when we want to remove the newClient button, the one that @dmitrydvornichenko describes and when the user has reached the limit configured by --max-number-client-config.
If the user has reached limit we might change the color of the button, or send an alert directly at the click of the button and not need to direct user to the NewClient.svelte.

Another use for this function to communicate to the front end i something not related to this issue, but to make "default config name" configurable from the back end.

I also agree that this feature would be useful, especially when it comes to the reached limit of configs per user.