[Module Request] ns_fset

[Juliaria08]

ns_fset would act the same as nickserv's set except it'd be oper only (making a fset privilege maybe in some other privilege), and it'd use the following syntax: FSET <user> <setting> <parameters>.

[ilbelkyr]

I don't think this would be a good idea. A lot of things currently controlled by the NickServ SET command are either account settings that network staff shouldn't need to touch (e.g. SET LANGUAGE, SET PRIVMSG) or deal with credentials (e.g. SET PASSWORD, SET EMAIL, SET PUBKEY). In the former case, I don't really see the use case; in the latter case, authentication-relevant matters ought to be handled carefully, and I don't think FSET would appropriately address this.

To go into some more detail on the latter: There are already dedicated commands such as SENDPASS, RESETPASS, and RETURN that include additional logic and precautions for overriding login credentials, while also being clear about the intent and generating noisy log output to ensure proper accountability; if these don't suffice, we'd prefer to understand your intended use case and figure out a more suitable solution.

For these reasons, we consider FSET to be a bad solution. We would however be happy for you to open an issue detailing your use case so we can try to address your requirements more directly instead.

[Juliaria08]

I don't think this would be a good idea. A lot of things currently controlled by the NickServ SET command are either account settings that network staff shouldn't need to touch (e.g. SET LANGUAGE, SET PRIVMSG) or deal with credentials (e.g. SET PASSWORD, SET EMAIL, SET PUBKEY). In the former case, I don't really see the use case; in the latter case, authentication-relevant matters ought to be handled carefully, and I don't think FSET would appropriately address this.

And making use of this feature require a privilege that's not granted by the normal network staff permission set?, that way network staff can't touch it, only specific people that are a bit more trusted.

To go into some more detail on the latter: There are already dedicated commands such as SENDPASS, RESETPASS, and RETURN that include additional logic and precautions for overriding login credentials, while also being clear about the intent and generating noisy log output to ensure proper accountability; if these don't suffice, we'd prefer to understand your intended use case and figure out a more suitable solution.

The feature would log all the actions that happen trough FSET with the same noisy outputs. And even then, if atheme doesn't want it to be used, it could just taint atheme when loaded.

For these reasons, we consider FSET to be a bad solution. We would however be happy for you to open an issue detailing your use case so we can try to address your requirements more directly instead.

If implemented could it have a feature to be able to edit taxonomy data and all internal atheme data or would that lower the chances of FSET being implemented in the first place?