[Feature Request] Add ability do disallow normal users to change their ident, add/remove/edit networks/servers and quitmsg #922

New Issue

2026-10-05T04:52:48+02:00

adam commented

2026-10-05 04:52:48 +02:00

After a brief discussion with MetaNova in IRC and advised by him, i decided to open this feature request.

This feature was implemented by PanicBNC here with a special flag named Premium.

Small IRC excerpt:

[00:10:22] <EliteGod> I'm heading to bed. I'm just leaving a small request here: I've used a PanicBNC custom build for some time. in that build normal users couldn't change their ident, add/remove networks/servers (via IRC or webpanel). is there anyone interested in adapting those changes to znc 1.7.4 in exchange of some sort of Patreon or something like that?
[00:11:26] <MetaNova> if you open a ticket (feature request) I'll put money towards a bounty on it
[00:12:31] <EliteGod> I'll do it tomorrow for sure. do you need the PanicBNC build (they have a GitHub one) to see the changes they've made?
[00:13:04] <EliteGod> it would be just awesome for people that want to provide a public ZNC service
[00:13:08] <MetaNova> relevant links to examples of the implementation elsewhere should be included in the ticket
[00:13:20] <MetaNova> for reference
[00:14:25] <MetaNova> and, yes, I agree: having the ability to prevent users from changing various aspects about their user (ident response, realname, quitmsg, and even the ability to add/remove networks/servers) be part of native ZNC would simplify a good many providers' lives

As stated by MetaNova this would help providers and simplify their lives, as probably most of users that run ZNC personally have only one user with all the networks they need.

What i think that should be blocked by default:

Deny SetBindHost (checked by default)
Ability to change the ident
Ability to add/remove/edit servers/networks
Ability to change realname
Ability to change quitmsg

All of this should be blocked via IRC commands/webpanel.

@magnum7385
Feel free to put the bounty on this and add your ideas.

PS: Sorry if my English is bad but i'm Portuguese

After a brief discussion with MetaNova in IRC and advised by him, i decided to open this feature request. This feature was implemented by PanicBNC [here](https://github.com/PanicBNC-Dev/ZNC) with a special flag named `Premium`. ##### Small IRC excerpt: ``` [00:10:22] <EliteGod> I'm heading to bed. I'm just leaving a small request here: I've used a PanicBNC custom build for some time. in that build normal users couldn't change their ident, add/remove networks/servers (via IRC or webpanel). is there anyone interested in adapting those changes to znc 1.7.4 in exchange of some sort of Patreon or something like that? [00:11:26] <MetaNova> if you open a ticket (feature request) I'll put money towards a bounty on it [00:12:31] <EliteGod> I'll do it tomorrow for sure. do you need the PanicBNC build (they have a GitHub one) to see the changes they've made? [00:13:04] <EliteGod> it would be just awesome for people that want to provide a public ZNC service [00:13:08] <MetaNova> relevant links to examples of the implementation elsewhere should be included in the ticket [00:13:20] <MetaNova> for reference [00:14:25] <MetaNova> and, yes, I agree: having the ability to prevent users from changing various aspects about their user (ident response, realname, quitmsg, and even the ability to add/remove networks/servers) be part of native ZNC would simplify a good many providers' lives ``` As stated by MetaNova this would help providers and simplify their lives, as probably most of users that run ZNC personally have only one user with all the networks they need. ##### What i think that should be blocked by default: Deny SetBindHost (checked by default) Ability to change the ident Ability to add/remove/edit servers/networks Ability to change realname Ability to change quitmsg All of this should be blocked via IRC commands/webpanel. @magnum7385 Feel free to put the bounty on this and add your ideas. PS: Sorry if my English is bad but i'm Portuguese

adam closed this issue

2026-10-05 04:52:48 +02:00

adam commented

2026-10-05 04:52:49 +02:00

I added a bounty, and there are a couple immediate things I'd like to mention:

If we're concerned with the user's abilities to edit certain things about themselves, perhaps they could also be denied setting CTCP responses.
Ideally, and this is on a bit of a tangent from the main purpose here, I'd very much like to see the ability to restrict certain modules from being loaded by a regular user, without having to resort to DenyLoadMod. An immediate example of this is (again from a provider's standpoint) where a user (or many users) would have no benefit or use for actual logs, so prevent *log from being loaded.

Bounty

I added a bounty, and there are a couple immediate things I'd like to mention: 1. If we're concerned with the user's abilities to edit certain things about themselves, perhaps they could also be denied setting CTCP responses. 2. Ideally, and this is on a bit of a tangent from the main purpose here, I'd very much like to see the ability to restrict certain modules from being loaded by a regular user, without having to resort to DenyLoadMod. An immediate example of this is (again from a provider's standpoint) where a user (or many users) would have no benefit or use for actual logs, so prevent *log from being loaded. [Bounty](https://www.bountysource.com/issues/80133504-feature-request-add-ability-do-disallow-normal-users-to-change-their-ident-add-remove-edit-networks-servers-and-quitmsg)

adam commented

2026-10-05 04:52:49 +02:00

2. Ideally, and this is on a bit of a tangent from the main purpose here, I'd very much like to see the ability to restrict certain modules from being loaded by a regular user, without having to resort to DenyLoadMod. An immediate example of this is (again from a provider's standpoint) where a user (or many users) would have no benefit or use for actual logs, so prevent *log from being loaded.

I would like to see this also. In the meantime, what I do is rename the modules in ./znc-master/modules from something like log.cpp to log.cpp.bak, which works for now.

P.S. I added $50 to the bounty. Hopefully this gets done!

> 2. Ideally, and this is on a bit of a tangent from the main purpose here, I'd very much like to see the ability to restrict certain modules from being loaded by a regular user, without having to resort to DenyLoadMod. An immediate example of this is (again from a provider's standpoint) where a user (or many users) would have no benefit or use for actual logs, so prevent *log from being loaded. I would like to see this also. In the meantime, what I do is rename the modules in ./znc-master/modules from something like log.cpp to log.cpp.bak, which works for now. P.S. I added $50 to the bounty. Hopefully this gets done!

adam commented

2026-10-05 04:52:50 +02:00

I started on that one: https://github.com/mocig/znc/tree/issue-1682
Deny SetBindHost (checked by default) => DONE
Ability to change the ident => DONE
Ability to add/remove/edit servers/networks => IN WORK
Ability to change realname => DONE
Ability to change quitmsg => DONE
Ability to restrict certain modules from being loaded by a regular user => NEXT TASK

Please test, I did. Translations I'll add in the and, I can provide German,English,Spanish and Portuguese. All others I leave to the community.

I started on that one: https://github.com/mocig/znc/tree/issue-1682 Deny SetBindHost (checked by default) => DONE Ability to change the ident => DONE Ability to add/remove/edit servers/networks => IN WORK Ability to change realname => DONE Ability to change quitmsg => DONE Ability to restrict certain modules from being loaded by a regular user => NEXT TASK Please test, I did. Translations I'll add in the and, I can provide German,English,Spanish and Portuguese. All others I leave to the community.

adam commented

2026-10-05 04:52:51 +02:00

Ability to add/remove/edit servers/networks => DONE
Please test and leave feedback.
When DenySetConn is set now normal users cant

add/del networks
change networkname
add/del/edit servers

but still can edit network parameters which I think user should be able to unless the other restrictions (ident, realname etc) are blocked.

Ability to restrict certain modules from being loaded by a regular user => IN WORK

Ability to add/remove/edit servers/networks => DONE Please test and leave feedback. When DenySetConn is set now normal users cant - add/del networks - change networkname - add/del/edit servers but still can edit network parameters which I think user should be able to unless the other restrictions (ident, realname etc) are blocked. Ability to restrict certain modules from being loaded by a regular user => IN WORK

adam commented

2026-10-05 04:52:51 +02:00

When DenySetConn is set now normal users cant

add/del networks
change networkname
add/del/edit servers

I assume that DenySetConn is set by default?

> When DenySetConn is set now normal users cant > >add/del networks >change networkname >add/del/edit servers I assume that DenySetConn is set by default?

adam commented

2026-10-05 04:52:52 +02:00

DenySetBindHost
DenySetIdent
DenySetConn
DenySetRealName
DenySetQuitMsg

all set by default, yes

You can build and test/check. All whats checked done on the list is on branch: issue-1682
https://github.com/mocig/znc/tree/issue-1682

git clone -b issue-1682 https://github.com/mocig/znc.git
cd znc
git submodule update --init --recursive

then follow the Readme.md build instructions eigher using cmake or autogen.sh, configure, make

DenySetBindHost DenySetIdent DenySetConn DenySetRealName DenySetQuitMsg all set by default, yes You can build and test/check. All whats checked done on the list is on branch: issue-1682 https://github.com/mocig/znc/tree/issue-1682 ``` git clone -b issue-1682 https://github.com/mocig/znc.git cd znc git submodule update --init --recursive ``` then follow the Readme.md build instructions eigher using cmake or autogen.sh, configure, make

adam commented

2026-10-05 04:52:53 +02:00

Well, I just finished reviewing the code for modules and how they're working. Since the same module can be loaded and configured in 3 diffrent locations the solution I think to solve the request at best is to add a new menu which allowes to declare modules as 'admin only'. Menu shows a list of all modules and if they're loadable global/network/user (informational) and in case they're marked as 'admin only' a normal user won't be able to load them manualy neigher they will load for them on start. So if you even would mark 'log' as global module it won't load for non-admin users. I'll also have to force that already loaded modules are unloaded in case they get marked as 'admin only' but already loaded for a running user.

Opinions please, before I implement the functionality on all levels.

Well, I just finished reviewing the code for modules and how they're working. Since the same module can be loaded and configured in 3 diffrent locations the solution I think to solve the request at best is to add a new menu which allowes to declare modules as 'admin only'. Menu shows a list of all modules and if they're loadable global/network/user (informational) and in case they're marked as 'admin only' a normal user won't be able to load them manualy neigher they will load for them on start. So if you even would mark 'log' as global module it won't load for non-admin users. I'll also have to force that already loaded modules are unloaded in case they get marked as 'admin only' but already loaded for a running user. ![image](https://user-images.githubusercontent.com/29002227/68067132-550d2000-fd08-11e9-91c8-eb6ed5010399.png) Opinions please, before I implement the functionality on all levels.

adam commented

2026-10-05 04:52:53 +02:00

Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine.

So if you even would mark 'log' as global module it won't load for non-admin users

Non-admin users can't load anything global anyway.

Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine. > So if you even would mark 'log' as global module it won't load for non-admin users Non-admin users can't load anything global anyway.

adam commented

2026-10-05 04:52:54 +02:00

Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine.

On the provider point of view, this would be the best way.

Cheers

> Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine. On the provider point of view, this would be the best way. Cheers

adam commented

2026-10-05 04:52:55 +02:00

Non-provider use case is much more common than the provider use case. There are only a few providers, and many more users who have their own ZNC instance. Providers can (and should) configure all the settings as they wish anyway.

Non-provider use case is much more common than the provider use case. There are only a few providers, and many more users who have their own ZNC instance. Providers can (and should) configure all the settings as they wish anyway.

adam commented

2026-10-05 04:52:55 +02:00

Then I'd suggest that those options should be at the top of User.cpp or znc.cpp so we could change them from False to True without having to search much through the files, if I make myself understandable.

Then I'd suggest that those __options__ should be at the top of _User.cpp_ or _znc.cpp_ so we could change them from `False` to `True` without having to search much through the files, if I make myself understandable.

adam commented

2026-10-05 04:52:56 +02:00

Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine.

Honest answer: Because that's the request and that's what the bounty is pledged on.
Reasonable answer: It has to be true or false as default, and both sides have their arguments. And before we get into some meta discussion about 'should money overwrite a default which maybe more users whould disagree on' I'll share my point of view: As a programmer my job is to solve problemlems and not discuss about them.

So let's discuss abolut the Solution: I'll add a new option on the settings section named 'Deny by default' which is false by default. So providers can check that one time after install and have their default on deny while all other users can just use it as DarthGandalf suggested.

I think that gives providers there requested feature while not disrespecting the opensource idea or the great team maintaining znc in the first place.

Can both sides live with that?

> Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine. - Honest answer: Because that's the request and that's what the bounty is pledged on. - Reasonable answer: It has to be true or false as default, and both sides have their arguments. And before we get into some meta discussion about 'should money overwrite a default which maybe more users whould disagree on' I'll share my point of view: As a programmer my job is to solve problemlems and not discuss about them. So let's discuss abolut the Solution: I'll add a new option on the settings section named 'Deny by default' which is false by default. So providers can check that one time after install and have their default on deny while all other users can just use it as DarthGandalf suggested. I think that gives providers there requested feature while not disrespecting the opensource idea or the great team maintaining znc in the first place. Can both sides live with that?

adam commented

2026-10-05 04:52:57 +02:00

For me that's perfectly reasonable.
So providers just need to check that and done.
I was wondering if you could add a boolean(?) thing somewhere in znc.cpp or something like that so we could edit it before compiling?
If not, for me your solution is fine

For me that's perfectly reasonable. So providers just need to check that and done. I was wondering if you could add a boolean(?) thing somewhere in znc.cpp or something like that so we could edit it before compiling? If not, for me your solution is fine

adam commented

2026-10-05 04:52:58 +02:00

As a programmer my job is to solve problemlems and not discuss about them.

A good programmer discusses it with customers and other interested parties instead of taking the request as granted :)

I don't see the point of 'Deny by default' option. What exactly it would do?

@TheMythPT if you wish to edit source code before compiling, it's possible regardless of how the feature is implemented. Therefore, I think these options should be runtime, not compile time.

> As a programmer my job is to solve problemlems and not discuss about them. A good programmer discusses it with customers and other interested parties instead of taking the request as granted :) I don't see the point of 'Deny by default' option. What exactly it would do? @TheMythPT if you wish to edit source code before compiling, it's possible regardless of how the feature is implemented. Therefore, I think these options should be runtime, not compile time.

adam commented

2026-10-05 04:52:58 +02:00

A good programmer discusses it with customers and other interested parties instead of taking the request as granted :)

I agree, and I'm totaly fine in discussion about the solution but I'm not on discussion what default is better or if the person who is donating the payment is 'right' just because he pais.

What's your opinion about my solution suggestion? Is that fine for the znc team that way?

> A good programmer discusses it with customers and other interested parties instead of taking the request as granted :) I agree, and I'm totaly fine in discussion about the solution but I'm not on discussion what default is better or if the person who is donating the payment is 'right' just because he pais. What's your opinion about my solution suggestion? Is that fine for the znc team that way?

adam commented

2026-10-05 04:52:59 +02:00

I was wondering how this would affect users already added to the ZNC.
Will they be blocked too?

I was wondering how this would affect users already added to the ZNC. Will they be `blocked` too?

adam commented

2026-10-05 04:53:00 +02:00

I was wondering how this would affect users already added to the ZNC.
Will they be blocked too?

Existing users will be added with default, so if you would run my branch now on an existing config it would add the new Deny items to all users and set them true (except DenySetBindHost, which will stay at the value it has already for that user)

> I was wondering how this would affect users already added to the ZNC. > Will they be `blocked` too? Existing users will be added with default, so if you would run my branch now on an existing config it would add the new Deny items to all users and set them true (except DenySetBindHost, which will stay at the value it has already for that user)

adam commented

2026-10-05 04:53:00 +02:00

I don't see the point of 'Deny by default' option. What exactly it would do?

It defines if a new user has Deny flags set to true or false by default. So a provider can just switch that one flag and all new users will get Deny set to true, while all other users can just leave it as it is and Deny will be set to false. So it will end up with the default you see more reasoble but an ISP can change his default with a single click on his own instance

> I don't see the point of 'Deny by default' option. What exactly it would do? It defines if a new user has Deny flags set to true or false by default. So a provider can just switch that one flag and all new users will get Deny set to true, while all other users can just leave it as it is and Deny will be set to false. So it will end up with the default you see more reasoble but an ISP can change his default with a single click on his own instance

adam commented

2026-10-05 04:53:01 +02:00

I was wondering if Restricted wouldn't be a better option name.
After all, we are putting restrictions on users when we provide a public service.

I was wondering if `Restricted` wouldn't be a better option name. After all, we are putting restrictions on users when we provide a public service.

adam commented

2026-10-05 04:53:02 +02:00

I was wondering if Restricted wouldn't be a better option name.
After all, we are putting restrictions on users when we provide a public service.

How to 'display' it can be done by adding the corrosponding translations. For me it's a flag which denies to set something, so I called it DenySetX, following the style given by the original code provide by DenySetBindHost. Style should be consistent in my opinion so all flags should work in the same way and share the same 'style' or it gets confusing for programmers aswell for users.

> I was wondering if `Restricted` wouldn't be a better option name. > After all, we are putting restrictions on users when we provide a public service. How to 'display' it can be done by adding the corrosponding translations. For me it's a flag which denies to set something, so I called it DenySetX, following the style given by the original code provide by DenySetBindHost. Style should be consistent in my opinion so all flags should work in the same way and share the same 'style' or it gets confusing for programmers aswell for users.

adam commented

2026-10-05 04:53:02 +02:00

Style should be consistent in my opinion so all flags should work in the same way and share the same 'style' or it gets confusing for programmers aswell for users.

Makes sense, yes.
For me, so far, I'm happy with the manner you're implementing it.
I'll try it probably later on (I'm on mobile now) and give some feedback.
Thanks for the effort you're putting on making this happen.

> Style should be consistent in my opinion so all flags should work in the same way and share the same 'style' or it gets confusing for programmers aswell for users. Makes sense, yes. For me, so far, I'm happy with the manner you're implementing it. I'll try it probably later on (I'm on mobile now) and give some feedback. Thanks for the effort you're putting on making this happen.

adam commented

2026-10-05 04:53:03 +02:00

For me, so far, I'm happy with the manner you're implementing it.

Well, the znc team won't accept a pull request till their point of view is respected too. So let's see what's DarthGandalf opinion on my suggestion.

> For me, so far, I'm happy with the manner you're implementing it. Well, the znc team won't accept a pull request till their point of view is respected too. So let's see what's DarthGandalf opinion on my suggestion.

adam commented

2026-10-05 04:53:03 +02:00

Yes, true. But as @DarthGandalf said above:

Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine.

And:

Non-provider use case is much more common than the provider use case. There are only a few providers, and many more users who have their own ZNC instance. Providers can (and should) configure all the settings as they wish anyway.

If the DenySetConn is set to False by default, it will respect the idea behind the software so far (I think).

Yes, true. But as @DarthGandalf said above: > Why do you want to deny everything by default? It's good to have the option to deny, but I think the current defaults (to allow) are fine. And: > Non-provider use case is much more common than the provider use case. There are only a few providers, and many more users who have their own ZNC instance. Providers can (and should) configure all the settings as they wish anyway. If the DenySetConn is set to `False` by default, it will respect the idea behind the software so far (I think).

adam commented

2026-10-05 04:53:04 +02:00

The suggestion to add a system-setting 'DenyByDefault' would leave all Flags with False as he stated, but enables that the 'default' beheaviour can be changed with marking a single checkbox on the settings page. So both parties should be fine then.

The suggestion to add a system-setting 'DenyByDefault' would leave all Flags with False as he stated, but enables that the 'default' beheaviour can be changed with marking a single checkbox on the settings page. So both parties should be fine then.

adam commented

2026-10-05 04:53:05 +02:00

It defines if a new user has Deny flags set to true or false by default

Currently the recommended way to have predefined setting for new users is to have a template user, then when creating a new user, clone that template user instead. I don't think a single global option of what to do with new users should be part of this change; that may require bigger changes and discussions.

Also interaction of this single setting and existing users is unclear: does the provider need to be sure to not accidentally run the upgraded service before manually setting the config in znc.conf? Otherwise ZNC on startup would apply "false" to all users, if I understood your proposal right.
If the provider wants to apply a certain setting to all existing users, we should have a way to do something like:

/msg *controlpanel set DenySetQuitMsg * false
/msg *controlpanel set DenySetRealName * false

...except that currently controlpanel doesn't accept * as username. Adding that feature to controlpanel is orthogonal to user permissions, but it removes this special case of applying a default deny setting to existing users.

> It defines if a new user has Deny flags set to true or false by default Currently the recommended way to have predefined setting for new users is to have a template user, then when creating a new user, clone that template user instead. I don't think a single global option of what to do with new users should be part of this change; that may require bigger changes and discussions. Also interaction of this single setting and existing users is unclear: does the provider need to be sure to not accidentally run the upgraded service before manually setting the config in znc.conf? Otherwise ZNC on startup would apply "false" to all users, if I understood your proposal right. If the provider wants to apply a certain setting to all existing users, we should have a way to do something like: ``` /msg *controlpanel set DenySetQuitMsg * false /msg *controlpanel set DenySetRealName * false ``` ...except that currently controlpanel doesn't accept `*` as username. Adding that feature to controlpanel is orthogonal to user permissions, but it removes this special case of applying a default deny setting to existing users.

adam commented

2026-10-05 04:53:06 +02:00

Also interaction of this single setting and existing users is unclear: does the provider need to be sure to not accidentally run the upgraded service before manually setting the config in znc.conf?

The way I did on the code is that the default will auto apply and get set auto on all users which already exists. And I have to agree on one point here: It will instant Deny all users something they werre allowed todo before. So the default has to be false.

I'll change the default to false but add the other option to the setting. It's optional and maybe 'not needed' but it also won't hurt anyone, right?

> Also interaction of this single setting and existing users is unclear: does the provider need to be sure to not accidentally run the upgraded service before manually setting the config in znc.conf? The way I did on the code is that the default will auto apply and get set auto on all users which already exists. And I have to agree on one point here: It will instant Deny all users something they werre allowed todo before. So the default has to be false. I'll change the default to false but add the other option to the setting. It's optional and maybe 'not needed' but it also won't hurt anyone, right?

adam commented

2026-10-05 04:53:06 +02:00

It adds code complexity to solve something which can be solved in a much nicer way. And even when controlpanel gains the bulk-edit feature, for backward compatibility we'd have to maintain the old setting you're adding now.

Btw, I hope you added some tests?

It adds code complexity to solve something which can be solved in a much nicer way. And even when controlpanel gains the bulk-edit feature, for backward compatibility we'd have to maintain the old setting you're adding now. Btw, I hope you added some tests?

adam commented

2026-10-05 04:53:07 +02:00

for backward compatibility we'd have to maintain the old setting you're adding now.

true and legit point. I'll provide an external patchfile then for 'edit code before compile'. ISPs can maintain that themself and it's not part of the repro, so it won't add anything on the backward combanility stack and users like TheMythPT can still apply their needs easy without diving into code. Maintain the patchfile won't be part of ZNC teams resposibility then.

Btw, I hope you added some tests?

Translations and tests I'll do at the end. Still working on the 'Deny normal users from loading certain modules' which is part of the feature request here.

> for backward compatibility we'd have to maintain the old setting you're adding now. true and legit point. I'll provide an external patchfile then for 'edit code before compile'. ISPs can maintain that themself and it's not part of the repro, so it won't add anything on the backward combanility stack and users like TheMythPT can still apply their needs easy without diving into code. Maintain the patchfile won't be part of ZNC teams resposibility then. > Btw, I hope you added some tests? Translations and tests I'll do at the end. Still working on the 'Deny normal users from loading certain modules' which is part of the feature request here.

adam commented

2026-10-05 04:53:07 +02:00

Honest answer: Because that's the request and that's what the bounty is pledged on.

I would like these options to be available, but toggled off by default. Normal use case outweighs provider use-case, in my opinion. Providers should already have a template user which should be cloned for new user creation (presumably with these various Deny options set), or have a system in place to toggle these options on full user creation (such as via *controlpanel). This is assuming "Deny by default" isn't available.

I like the option of "Deny by default" to have these options toggled on for new user creation, though, that would simplify a lot of the above.

> * Honest answer: Because that's the request and that's what the bounty is pledged on. I would like these options to be available, but toggled off by default. Normal use case outweighs provider use-case, in my opinion. Providers should already have a template user which should be cloned for new user creation (presumably with these various Deny options set), or have a system in place to toggle these options on full user creation (such as via *controlpanel). This is assuming "Deny by default" isn't available. I like the option of "Deny by default" to have these options toggled on for new user creation, though, that would simplify a lot of the above.

adam commented

2026-10-05 04:53:08 +02:00

I would like these options to be available, but toggled off by default. Normal use case outweighs provider use-case, in my opinion. Providers should already have a template user which should be cloned for new user creation (presumably with these various Deny options set), or have a system in place to toggle these options on full user creation (such as via *controlpanel). This is assuming "Deny by default" isn't available.

The options are on my branch linked above fully implemented and ready for testing. Right now they default to 'Deny it' but before doing a pull request I'll change them to not be default.

Reason 1: I agree with the ZNC team that an update of znc on a running config should not change the permissions or beheaviour of already existing users just because I upgraded znc. But that happends if you upgrade my branch now.
Reason 2: I'm not a fan of running forks, so on all changes I do the ZNC team will have the last word. If they don't agree on a pull request after work is done we just will end up with an 'ZNC ISP edition' which has to merge every change the main znc is getting on top. Double work without any reason.

I like the option of "Deny by default" to have these options toggled on for new user creation, though, that would simplify a lot of the above.

I will not add that config option, because I agree aswell with the ZNC team here: A new option will have to get maintained in future versions to keep backwards compability, which is fine if that new feature is a killer. In our case it's just something which some users may like. Which of both defaults is the 'better' one is 'taste' in that case and therefore the taste I have to care of is to respect the ZNC team onces. I'm just guest on that code.

> I would like these options to be available, but toggled off by default. Normal use case outweighs provider use-case, in my opinion. Providers should already have a template user which should be cloned for new user creation (presumably with these various Deny options set), or have a system in place to toggle these options on full user creation (such as via *controlpanel). This is assuming "Deny by default" isn't available. The options are on my branch linked above fully implemented and ready for testing. Right now they default to 'Deny it' but before doing a pull request I'll change them to not be default. - Reason 1: I agree with the ZNC team that an update of znc on a running config should not change the permissions or beheaviour of already existing users just because I upgraded znc. But that happends if you upgrade my branch now. - Reason 2: I'm not a fan of running forks, so on all changes I do the ZNC team will have the last word. If they don't agree on a pull request after work is done we just will end up with an 'ZNC ISP edition' which has to merge every change the main znc is getting on top. Double work without any reason. > I like the option of "Deny by default" to have these options toggled on for new user creation, though, that would simplify a lot of the above. I will not add that config option, because I agree aswell with the ZNC team here: A new option will have to get maintained in future versions to keep backwards compability, which is fine if that new feature is a killer. In our case it's just something which some users may like. Which of both defaults is the 'better' one is 'taste' in that case and therefore the taste I have to care of is to respect the ZNC team onces. I'm just guest on that code.

adam commented

2026-10-05 04:53:09 +02:00

In our case it's just something which some users may like.

You're welcome to implement the bulk-edit feature of controlpanel, which (together with already existing user cloning) covers that use case. However, if you're doing this only for the bounty, I don't know whether it's covered or not.

The options are on my branch linked above fully implemented and ready for testing

I haven't looked at the code at all yet, will do in the PR where it's possible to comment.

> In our case it's just something which some users may like. You're welcome to implement the bulk-edit feature of controlpanel, which (together with already existing user cloning) covers that use case. However, if you're doing this only for the bounty, I don't know whether it's covered or not. > The options are on my branch linked above fully implemented and ready for testing I haven't looked at the code at all yet, will do in the PR where it's possible to comment.

adam commented

2026-10-05 04:53:09 +02:00

You're welcome to implement the bulk-edit feature of controlpanel, which (together with already existing user cloning) covers that use case.

Fair enough.

However, if you're doing this only for the bounty, I don't know whether it's covered or not.

If that solution makes the donators marking the issue as solved, it is. I understand a donation on an opensource project more in a way to solve the issue in best interrest for both sides rather than just doing blind what I get paid for. In that case the ppl could just open a fork and hire a programmer to implent whatever they like.

I'll look into it.

> You're welcome to implement the bulk-edit feature of controlpanel, which (together with already existing user cloning) covers that use case. Fair enough. > However, if you're doing this only for the bounty, I don't know whether it's covered or not. If that solution makes the donators marking the issue as solved, it is. I understand a donation on an opensource project more in a way to solve the issue in best interrest for both sides rather than just doing blind what I get paid for. In that case the ppl could just open a fork and hire a programmer to implent whatever they like. I'll look into it.

adam commented

2026-10-05 04:53:10 +02:00

Sorry, but I've been caught by real life and too much work.

@mocig could you please tell me what's the current status of the fixes?

Sorry, but I've been caught by real life and too much work. @mocig could you please tell me what's the current status of the `fixes`?

adam commented

2026-10-05 04:53:11 +02:00

Unfortunately, I've discovered a bug in your branch @mocig

If you go to Manage Users you pick a user, you Change Deny SetIdent to false by unchecking the box, you click on Save and return and then you open the management of the same user again, the Deny SetIdent box will be checked again although in the conf file it's marked as False

I believe that somehow the webpanel isn't getting the proper state of an option?

Cheers!

Unfortunately, I've discovered a bug in your branch @mocig If you go to `Manage Users` you pick a user, you Change `Deny SetIdent` to false by unchecking the box, you click on `Save and return` and then you open the management of the same user again, the `Deny SetIdent` box will be checked again although in the conf file it's marked as `False` I believe that somehow the webpanel isn't getting the proper state of an option? Cheers!

adam commented

2026-10-05 04:53:12 +02:00

Sorry for the late answer, company I'm working for is 'deadline-sprint', which means 15hrs on screen is all whats left of the day ;)

Unfortunately, I've discovered a bug in your branch @mocig

I'll look into that tomorrow and fix it. I didn't pushed the changes for 'admin modules' so far to keep the two topics involved clean, so we should get the new flags done first, issue a pull-request and then add the other feature.

Will report back tomorrow

Sorry for the late answer, company I'm working for is 'deadline-sprint', which means 15hrs on screen is all whats left of the day ;) > Unfortunately, I've discovered a bug in your branch @mocig I'll look into that tomorrow and fix it. I didn't pushed the changes for 'admin modules' so far to keep the two topics involved clean, so we should get the new flags done first, issue a pull-request and then add the other feature. Will report back tomorrow

adam commented

2026-10-05 04:53:12 +02:00

Hello @mocig! I hope you're fine and I suppose you've been caught by real life! 😀

Did you get any time to check the issue I've reported?

Thanks in advance!

Hello @mocig! I hope you're fine and I suppose you've been caught by real life! :grinning: Did you get any time to check the issue I've reported? Thanks in advance!

adam commented

2026-10-05 04:53:13 +02:00

Is this still awaiting a solution as well? I was considering working on this bounty next.

Is this still awaiting a solution as well? I was considering working on this bounty next.

adam commented

2026-10-05 04:53:14 +02:00

@mocig never sent the PR.
So I guess it is…

@mocig never sent the PR. So I guess it is…

adam commented

2026-10-05 04:53:14 +02:00

@braewoods for the time being, seems that @mocig didn't submitted any PR or did any further development on this feature.

Anyone is free to make this work so, if you think you can make it work, go ahead!

Cheers

@braewoods for the time being, seems that @mocig didn't submitted any PR or did any further development on this feature. Anyone is free to make this work so, if you think you can make it work, go ahead! Cheers

adam commented

2026-10-05 04:53:15 +02:00

I'll look into it later. Right now trying to finalize the other PR.

I'll look into it later. Right now trying to finalize the other PR.

adam commented

2026-10-05 04:53:16 +02:00

I was wondering if this would be possible to be made as a module instead something core?
Can a module override some functions?
If so, if the module was loaded we'd have the ISP behaviour, otherwise normal behaviour would be used.
In case of this could be done via module, we'd need to tick some Enable ISP mode in the znc webpanel and settings chosen from there onwards would be applied to already registered users (like the the Deny set BindHost, etc).

I was wondering if this would be possible to be made as a module instead something core? Can a module `override` some functions? If so, if the module was loaded we'd have the _ISP_ behaviour, otherwise normal behaviour would be used. In case of this could be done via module, we'd need to tick some `Enable ISP mode` in the znc webpanel and settings chosen from there onwards would be applied to already registered users (like the the Deny set BindHost, etc).

adam commented

2026-10-05 04:53:16 +02:00

A module could e.g. just overwrite some settings every 10 minutes. That's not really what you have in mind, but would have a similar effect.

A module could e.g. just overwrite some settings every 10 minutes. That's not really what you have in mind, but would have a similar effect.

adam commented

2026-10-05 04:53:17 +02:00

A module can override some functions. But functionality of changing your
settings is not currently a function overridable by a module.

сб, 31 окт. 2020 г. в 22:01, PeGaSuS notifications@github.com:

I was wondering if this would be possible to be made as a module instead
something core?
Can a module override some functions?
If so, if the module was loaded we'd have the ISP behaviour, otherwise
normal behaviour would be used.
In case of this could be done via module, we'd need to tick some Enable
ISP mode in the znc webpanel and settings chosen from there onwards would
be applied to already registered users (like the the Deny set BindHost,
etc).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/znc/znc/issues/1682#issuecomment-719993730, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACPLZDUBNTVJL626GM6IQ3SNSCLVANCNFSM4IVAR7SQ
.

A module can override some functions. But functionality of changing your settings is not currently a function overridable by a module. сб, 31 окт. 2020 г. в 22:01, PeGaSuS <notifications@github.com>: > I was wondering if this would be possible to be made as a module instead > something core? > Can a module override some functions? > If so, if the module was loaded we'd have the *ISP* behaviour, otherwise > normal behaviour would be used. > In case of this could be done via module, we'd need to tick some Enable > ISP mode in the znc webpanel and settings chosen from there onwards would > be applied to already registered users (like the the Deny set BindHost, > etc). > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/znc/znc/issues/1682#issuecomment-719993730>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACPLZDUBNTVJL626GM6IQ3SNSCLVANCNFSM4IVAR7SQ> > . >

adam commented

2026-10-05 04:53:18 +02:00

A module can override some functions. But functionality of changing your
settings is not currently a function overridable by a module.

So, the only option is to add it to the core with a ON/OFF toggle.
Then, the option could be called Enable ISP mode and default to off, since as already discussed there are more private users using ZNC than actually ZNC providers.
Now, the only question that really bugs me is: should this apply to already registered users or only to newly created users?
This is because someone might be already providing a public ZNC service, with some users already registered before this option become a thing.

>A module can override some functions. But functionality of changing your settings is not currently a function overridable by a module. So, the only option is to add it to the core with a ON/OFF toggle. Then, the option could be called `Enable ISP mode` and default to off, since as already discussed there are more private users using ZNC than actually ZNC providers. Now, the only question that really bugs me is: should this apply to already registered users or only to newly created users? This is because someone might be already providing a public ZNC service, with some users already registered before this option become a thing.

adam commented

2026-10-05 04:53:18 +02:00

In theory, it should be possible to bulk-edit users via controlpanel
module. But this feature is implemented only for editing channels,
where you can already provide * to SetChan command when specifying
channel name.

вс, 1 нояб. 2020 г. в 14:11, PeGaSuS notifications@github.com:

A module can override some functions. But functionality of changing your
settings is not currently a function overridable by a module.

So, the only option is to add it to the core with a ON/OFF toggle.
Then, the option could be called Enable ISP mode and default to off, since as already discussed there are more private users using ZNC than actually ZNC providers.
Now, the only question that really bugs me is: should this apply to already registered users or only to newly created users?
This is because someone might be already providing a public ZNC service, with some users already registered before this option become a thing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

In theory, it should be possible to bulk-edit users via controlpanel module. But this feature is implemented only for editing channels, where you can already provide `*` to `SetChan` command when specifying channel name. вс, 1 нояб. 2020 г. в 14:11, PeGaSuS <notifications@github.com>: > > A module can override some functions. But functionality of changing your > settings is not currently a function overridable by a module. > > So, the only option is to add it to the core with a ON/OFF toggle. > Then, the option could be called Enable ISP mode and default to off, since as already discussed there are more private users using ZNC than actually ZNC providers. > Now, the only question that really bugs me is: should this apply to already registered users or only to newly created users? > This is because someone might be already providing a public ZNC service, with some users already registered before this option become a thing. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe.

adam commented

2026-10-05 04:53:19 +02:00

Bumped the bounty (now at $250)

Bumped the [bounty](https://www.bountysource.com/issues/80133504-feature-request-add-ability-do-disallow-normal-users-to-change-their-ident-add-remove-edit-networks-servers-and-quitmsg) (now at $250)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#922