Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[Proposal/Feature] More features for m_helpop #393

Shawn-Smith opened this Issue Dec 28, 2012 · 8 comments


None yet
4 participants

Shawn-Smith commented Dec 28, 2012

Currently the h usermode provided by this module is oper-only, I don't think this is an ideal setup. Opers already get marked with a usermode, o and are given a whois line to show that.

I was thinking that we could add two new oper-permission flags. oper/gets-usermode-o and helpop/gets-usermode-h.

Then users could easily alias /hlogin or something similar to /oper and have their network help staff login and get ONLY +h and the whois line associated with it.

Also, Unreal is selling a module that does things similar to this for nearly $80. It'd be nice for users to have a free alternative to that.

Unreal module


DjSlash commented Dec 28, 2012

I was suprised to see that m_helpop is providing that umode. It's more important function is to provide the /helpop command.

However, an oper doesn't have to get the h umode, you can set that in your config already. It's also possible in several ways to create helper accounts (using customtitle or setting up a restricted oper).

JDowny commented Dec 28, 2012

Don't most services packages set umode +h if you are given access (op) in the network help channel?

This is how I have mine setup anyway, anyone with op or above in the channel gets a +h set by services.

I guess the point is that I think this is already handled through services, at least in Anope. I'm sure Atheme does the same thing.


Shawn-Smith commented Dec 28, 2012

I think it's just Anope that does that. I still think it should be added for those who run service-less networks or services that don't support it.

JDowny commented Dec 28, 2012

Seems like a good idea. I'm sure a lot of nets would appreciate something like this, for easier delegation and recognition of help staff.

I see no issues with doing this through restricted oper classes really, everything is already in place to be able to lock this down pretty much, except the +o umode as you mention.

EDIT: I'm a tard and meant it is a good idea.


Shawn-Smith commented Dec 29, 2012

@DjSlash Using restricted oper settings the user will still get the usermode o and the whois line from opers. Since we have such a nice oper-configuration setup I still think it would be worthwhile to implement this.

SeLEct- commented Dec 30, 2012

Also wouldn't oper give them access to certain /stats command and snomasks?
Some people might not wanna give access like that to helpers, in that case, Shawn's idea is a better solution imo.


DjSlash commented Dec 30, 2012

This change would make an entirely new enitity, the way I see it. You are talking about new oper-permissions, but you mean you want someone to be able to get the Helper title while not being an oper. This can't be done without seperating those two things. Then all permissions should be checked to see if one is an oper or an helper and people probably want to have 'types' of helpers, each with different permissions. Helpers without +o are just normal users with an extra whois line. If the only thing you want to establish is vanity in the whois output, just use m_customtitle. It adds an whois-line (and/or a vhost) but doesn't provide any other permissions.


Shawn-Smith commented Dec 30, 2012

@DjSlash Helpers without +o are just normal users with an extra whois line.

Not true, you could give helpers certain oper-permissions. Such as channels/auspex, users/auspex, and channels/high-join-limit without marking them as an oper.

Helpers without +o are just normal users with an extra whois line.
Again, not true. Since the permissions and such are abstracted away from user-modes and are handled with internal permissions. With a bit of editing you could create a subclass of opers, called helpers, who would get user-mode +h instead of +o on 'oper up'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment