UnrealIRCd Forums

I just had a design question about the oper flag can_gkline.
This one flag gives access to three commands, /gline, /shun, and /spamfilter.

These seem like three majorly different levels of access, and I was wondering if there was a reason they were all on one oper flag instead of seperated out into three seperate flags.

On my network there is a level of operators that I want to have access to the /gline command, but definatly not /shun, and ideally not /spamfilter either although that one I'm not as concerned about.

Is there a way to do this in unreal 3.2.5, or lacking that, is there some logic behind this setup that I am just missing, which could be explained to me?

Currently the only two options I see are
a) Not give them /gline access and force/require this feature through services, and
b) A TCM bot script that monitors shun notices and instantly reverses them.

Right now I'm using option A, but a couple people have asked (read: complained and mostly been ignored) about not having direct access to the /gline command, and I wondered if there was any way to do this with out also giving access to the /shun command, which as a rule is not allowed at all on our network.

Thanks -- Dissy

Unreal was designed to work with services, so there are many things that need services to do. The Unreal coders have combined those 3 commands because they are all "TKL" commands. Because they are all the same type of command, it is logical to keep them grouped.

The option you are using as a solution is the best way. Services can have modules which can stop potentially abusive glines, which is a big advantage. I don't see why people would complain, as sending a gline through services is a whole 4 extra characters to type. So, tell your opers not to be lazy.

GLINE's SHUN's and SPAMFILTER's use the same oper flag but GZLINE's although a TKL command have a seperate oper flag. Just a minor point. Although i can see a very good reason to keep GZLINE and ZLINE seperate anyway.

- Access to Z:Lines over /spamfilter ;)
Maybe report it as bug (people with low access level cannot set /spamfilter actions, that require high access level) ?

Or maybe move /spamfilter to a seperate oper flag.

Jobe1986 wrote:Or maybe move /spamfilter to a seperate oper flag.

Is already suggested on bugs*. I've not changed it now because it would break all existing installations, something we don't really intend to do for 3.2* because it's in 'stable'.

For 3.3* it will be a separate flag for sure.

Thats nice to know thank you.

Personally i would as you have chosen suggest not to include it in the 3.2 branch since it is possible to have different versions of the 3.2 branch connected together and that would mean you could have the restriction on one server but not on another so an oper with the same flags on both servers could use /spamfilter on one but not the other.