Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[katsklaw]

1> send globops/nachat type message when user fails to pass requirements and modes are removed. Perhaps informing the user perhaps not. This could be a config setting or use your own db. This can be user defined as globops/wallops/chatops or adminchat/nachat.

2> optional removal of modes when users logout or suspended, again config item or db setting. <3 EVENT_NICK_LOGOUT and EVENT_NICK_SUSPENDED. This could double as a form of user level NOOP. Optionally, if you go the db route you would be able to suspend oper access without suspending the nick account via additional commands. Example: /os (un)suspend nick which would suspend oper access to na->display.

3> Adjustable requirements, ie make the minimum access level user defined, again conf or db.

[Jan Milants]

1 & 3 are on the planning for the next release..

nr 2 however looks like a bit more complicated... i think logout should be doable, but suspend works on nick level whereas access to oper is granted based on the nickgroup. so if a users' nick gets suspended that doesn't mean that per se his access to /oper is lost... removing oper modes would be almost impossible if the user changed to lets say an unregged xxx[away] nick.

i am planning another ircd_oper_list which allows the /oper based on access granted to a nickgroup.
and maybe on longer term an ns_oper which gives oper modes on identifying, but i don't really know what to do with flags yet.. would be just the basic oper modes +OaAN..

[katsklaw]

I understand, except I don't know what  a oper may do to deserve to have their nick suspended and not have their oper access suspended as well. Your module though and I'm just grateful that it exists at all

Additionally you wouldn't have to worry about xxx[away] because when a registered nick changes their nick, their na->status changes and is treated as an unidentified user until they ID to the new nick, which your module already accounts for. Anope already knows if xxx[away] is in the same group or not. If it is, then you return MOD_CONT, if it's not then you de-oper them.

I was also going at #2 to be more internal oper list driven than the nick/group based list. The module could optionally de-oper anyone that isn't on your modules allow list, id'd or not. THAT list can have a un/suspend feature that regulates who can oper and should be detectable via Anope's nick groups.