View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002094 | unreal | ircd | public | 2004-09-25 20:57 | 2007-04-27 06:40 |
| Reporter | JasonTik | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | duplicate | ||
| Summary | 0002094: Oper flags feature request | ||||
| Description | I am often annoyed at the confusing grouping of permissions in unreal. The oper flags system should be overhauled so that the grouping flags (oOCAaN) are optional, and permissions can be assigned individually without getting anything else. For example, currently a oper with only the flag helpop will also be locop. The flags locop, globop, admin, etc should be kept, but not added if they are not specificly given | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
This would break many config files, and I see no reason to do it. So let me see if I understand, you want to be able to create a netadmin who can't kill anyone... what good does that do? |
|
|
although it would not always make sense to grant one priviluege, but an other not, but it would allow more flexibility to distribute oper-rights... for example several Admins are more comfortable in adminstrating the server, and leave the user-contact to their opers - but every oper has to wear this +h -umode by default another example would be can_setq - if a network desides not to use umode for any admin, or just the services admins, which is their good right I think, they should have the possibility to remove that flag from conf and so noone can use it. I don't agree it would "break" config files, maybe there would be problems with configs now used if they were simply transfered to a new version as suggested here. But they have to be adapted as for every software-change... |
|
|
[quote]This would break many config files[/quote] Some confs I've seen list all the flags :p . But those are usually the n00b confs :P . [quote], and I see no reason to do it. So let me see if I understand, you want to be able to create a netadmin who can't kill anyone... what good does that do?[/quote] How about... a local oper that can't kline? A services admin that can't /sapart? A global oper that can't /notice $*.net (reserve wide noticing to Global)? Doesn't make sense actually that kline is automatic priv for local, but gline isn't for global... I can see the practicality of the inherited flags, but it sorta detracts from the flexibilty that is found everywhere else, and just doesn't seem to "fit". |
|
|
[quote]How about... a local oper that can't kline?[/quote] Why? [quote]A services admin that can't /sapart?[/quote] Well first off, there is no flag for sapart. Secondly, see that "sa"? That stands for "services admin." [quote]I can see the practicality of the inherited flags, but it sorta detracts from the flexibilty that is found everywhere else, and just doesn't seem to "fit".[/quote] I disagree. It makes things easier for everyone. <User> Someone is using clones in my channel, can you please help me! <Oper> Sorry, I don't have access to kline people <User> But your an admin aren't you??? <Oper> Yes, but all I have the ability to do is connect new servers, not kill or kline people This feature would serve to confuse people more than anything else imho. If it were added, there is no reason for all the "is an Administrator" "is a Network Administrator" etc., because those statements are now meaningless. There are no "levels" there are just random flags that can be arranged in any fashion. You can be an oper who can do everything, and a netadmin who can do nothing. I don't see the point. [quote]for example several Admins are more comfortable in adminstrating the server, and leave the user-contact to their opers - but every oper has to wear this +h -umode by default[/quote] This is the only good reason I've seen, however I think your solution is flawed. I'd say the correct solution is to simply remove the +h flag from +O, not to remove every flag from every level. |
|
|
Well, the service admin/netadmin stuff is a rather extreme example. I don't think an admin would neglict to give himself the flags necessary to manage his server :P . But the local oper thing... as I said, it's kinda funny how kline is automatic to local, but gline isn't automatic to global? And besides, perhaps I want a specific team of local opers with the sole responsibility over KLines on my server? For local opers not on the team, I simply don't give the kline flag. Of course, there is another way to look at this: instead of seperating the permissions from the operlevels... make the flags less dependant on the operlevel flags, so that I could have an oper block that has just the flags I want (no level specified). Currently you can do this, but opers will only get +O (+ whatever modes go with the flags you add, eg +h with helpop) no matter what you do. This breaks some of the global flags (eg, can_override, can_gkline, can_globalnotice, etc) which need the recognition of other servers (iow, +o not +O), and the only way to get that is to use at least the global flag, which may give flags you don't want. So perhaps have it that in this case (no level flag), a global operflag makes you get +o instead of +O (so that the flag works correctly). $0.02... |
|
|
codemastr, thats not what I meant Keep the grouping flags, but dont have someone without the o flag, but with the h flag, get locop |
|
|
And you will notice that most large nets have dedicated teams for specific purposes ANYHOW. This would stop them stepping on each others toes. |
|
|
[quote]Keep the grouping flags, but dont have someone without the o flag, but with the h flag, get locop[/quote] As I've already said, that won't happen. It's help OP. That means you must be an op to be +h. That's not going to change. |
|
|
>As I've already said, that won't happen. It's help OP. That means you must be an op to be +h. That's not going to change. Wouldn't having an oper block (to get the helpop flag) make you an op, regardless of other flags? But anyway, you've mentioned no less than 574984998456465165 times that you plan to remove +h... But still... *points at previous post* *edit* darn typos */edit* edited on: 2004-09-27 06:33 |
|
|
> This breaks some of the global flags (eg, can_override, can_gkline, can_globalnotice, etc) which need the recognition of other servers I fail to see the point here.. a locop is a *LOCAL* irc operator, it should NOT deal with *GLOBAL* issues. So it shouldn't be able to /gline, should not go trough modes/bans of (global) channels, etc. |
|
|
Well I'm not referring to the local flag itself.. I'm referring that when no level flag is given, local is half-assumed (you get +O but no perms except those listed; really in this situation, there's no sure sign that the person is supposed to be local or global, except what can be assumed from the flags that are present). And anyway, what if an admin does want a locop that can gline/override/etc? |
|
|
> Well I'm not referring to the local flag itself.. I'm ref[..] Sure, there could be more error checking. But certainly not more 'guess work'. > And anyway, what if an admin does want a locop that can gline/override/etc? See my previous post. I have made myself clear enough. |
|
|
Well, when local is given explicitly... yes I can understand that... For the "no level given" thing though... ugh... trying to think of a useful example, but best I come up with is this: a bot that you want only limited permissions: for example, BOPM. BOPM only needs permission to get the client connect/disconnect/killed/nickchange messages, and to use kline (if perserver) or gline (if using central scanner). Now, if I use a central BOPM, I would want it to have the can_gkline privilege (maybe can_globops if I want it to send online/offline/trigger notifications to ircops...), but in order to that I need to give it global, which gives it permissions it doesn't need. If I could simply just give it can_gkline (and maybe can_globops, see earlier note), I don't need to give it flags it doesn't need... Maybe after some thinking and/or sleep I can come up with something better... :) |
|
|
Hmm. Interesting. Being as I play with my flags on my 'modified' server (for fun) I have noticed the little quirks you all are reporting. I have a suggestion or two.. On a couple of nets I work on, They like to set 'helpops' on you before you get promoted to local ircop.. sure, giving you just the 'h' flag sets you +O with no permissions.. Now as for completely separating permissions from levels, i disagree. I think that +h should become a level instead of a permission, kind of how I changed the grouping of the usermodes on my server: hOoCAaN (modes) // hoOCAaN (flags) giving admins ability to allow an HelpOp-only Operblock so that these Helpers can do their /oper and show up as helper. ex: /oper blah password *** User (ident@myhost) is now a Help Operator (h) /whois User User :is available for help (no need to add a User :is a Help Operator, cos we already have a +h reply) $0.02 :-D |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-09-25 20:57 | JasonTik | New Issue | |
| 2004-09-25 22:25 |
|
Note Added: 0007790 | |
| 2004-09-25 23:17 | medice | Note Added: 0007791 | |
| 2004-09-26 05:35 | aquanight | Note Added: 0007794 | |
| 2004-09-26 16:05 |
|
Note Added: 0007796 | |
| 2004-09-26 16:25 | aquanight | Note Added: 0007797 | |
| 2004-09-26 16:35 | JasonTik | Note Added: 0007798 | |
| 2004-09-26 16:35 | w00t | Note Added: 0007799 | |
| 2004-09-26 16:55 |
|
Note Added: 0007801 | |
| 2004-09-27 06:32 | aquanight | Note Added: 0007806 | |
| 2004-09-27 06:33 | aquanight | Note Edited: 0007806 | |
| 2004-09-28 02:29 | syzop | Note Added: 0007813 | |
| 2004-09-28 02:33 | aquanight | Note Added: 0007815 | |
| 2004-09-28 02:43 | syzop | Note Added: 0007818 | |
| 2004-09-28 02:44 | syzop | Summary | Oper flags feature request for 3.2.2 => Oper flags feature request |
| 2004-09-28 03:19 | aquanight | Note Added: 0007819 | |
| 2004-11-02 12:06 | Zell | Note Added: 0008218 | |
| 2007-04-27 06:40 |
|
Relationship added | child of 0003241 |
| 2007-04-27 06:40 |
|
Status | new => closed |
| 2007-04-27 06:40 |
|
Resolution | open => duplicate |
