View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003683 | unreal | ircd | public | 2008-04-20 02:40 | 2015-07-09 18:48 |
| Reporter | Strawberry_Kittens | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| OS | Linux | OS Version | 2.6 | ||
| Summary | 0003683: HelpOp Login System | ||||
| Description | Currently the /oper command gives local operator regardless of what flags you put in it. I vote to change it so you can set JUST the helpop flag, and the user gets JUST the helpop flag. Or Write a HelpOp Login System similar to the /hlogin written by sysop. For the HelpOp Login System, here would be a sample syntax hlogin <name> { from { host1 *@*; //required host2 *@*; //optional <etc> }; password "<password>" { <auth-type>; }; //required modes "+/-"; //optional }; Possibly add a +H channel mode for HelpOp only channels also? And possibly look into allowing HelpOp's to join unlimited channels? | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
As an after though, possiblely join them to an optional channel? |
|
|
I think this is a good idea, I just want to make a not to developers... It would be nice for this to be a separate system, as Stawberry pointed out, a /helper <User> <Password> for this, and also allow a "join-on-helper" tag like IRCops have on oper up. Give them the ability to view /helpop requests etc. It's used in inspircd already as an optional oper flag, but i think a separate system would be nice. |
|
|
I think this would be a great idea. |
|
|
Isn't this the same as the paid module "Helpop Login System": http://www.vulnscan.org/customcoding#Helpop%20Login%20System |
|
|
I'm not familiar with it, so not sure, but probably similar yes. However with 3.3 planning to be more modular, a seperate helpop system would be a nice thing, and I liked the idea of it. |
|
|
I do agree it would be nice to see added. Just wondering if the author would appreciate losing money because of it though. Anyway might be an idea to consider some extra privileges via flags such as the ability to see real IP's of users for helpop's. |
|
|
I could understand if it would cost thousands and such, but are we really expecting that he's making thousands in a year with that module? And yes, extra privileges will be available, I'm not sure exactly what all the 'HelpOp' module offers, but I imagine this will be fairly different for the most part. |
|
|
I don't think Syzop will feel that expanding the Unreal community by given their wants will be that big of a deal. I'm sure he doesn't make much from the module since its sort of expensive for such a module someone could write, and as nate pointed, it would probably go into 3.3 |
|
|
it's ok. it's quite a basic/simple module (not like sql*/monitor), i don't mind getting such mods (or part thereof) integrated in core Unreal or have them shipped with Unreal as modules. |
|
|
Any new news on the status of this? |
|
|
If 0004157 was added, this feature would be inherited. |
|
|
Helpop stuff is kind of on the way out, actually. We are just deciding how and when to finish killing it off. It's strictly a vanity usermode at this point. |
|
|
What nenolod means is that /HELPOP no longer does anything with helpop (+h) users. Thus, the only thing +h does is add the 'is available for help' line. Of course, this raises the question if +h - at that point - is still a useful user mode. Could just as well use a module (or maybe 0004157) & then SWHOIS the user (yes that works for non-ircops too). ..except that current SWHOIS only allows for one line to be added, which may or may not be a problem if you want to display more than one line, but that could be changed. Then again, that's a different discussion. I know, this isn't directly where this issue is about, but it would change the way we deal with it ;) |
|
|
Any updates? I'd like to have a helpop login system added :) |
|
|
It seems obvious to me that some people still actively use the /helpop system and still see value in it. I for one and I've seen few others. I think the answer to sysop's "is it still useful" question is "yes it is still useful to some". A supported and included in Unreal's tarball module option is fine with me but I think if you modulize helpop, you should modulize all the features like modes/features. SA*, SET*, CHG*, NetAdmin, services-admin just to name a few as I'm sure there are some that find them equally useful/useless as helpops. I also think that in said process an optional config value of set::options::send-helpops-to [nick|#chan] would allow those that view the feature as useless to not have it, those that think the feature is a God send can having and any combination between so everyone is happy. Breaking up commands.so into something more configurable like a separate config file or autoload from a directory, which I think is slated for 3.4 iirc, would be a median solution instead of assuming "no one uses it anymore". Just my opinion. |
|
|
Exactly, better modularization is an important release goal (in my opinion even the main goal) for 3.4. Now (or when) +h only meaning is adding an 'is available for help' line to a WHOIS, then it's just a waste (as a user mode) [*]. But, there's a clear demand to have such functionality, which means we better just abstract it from +h / 'is available for help': make it so users can get an(y) swhois line in some way. Thinking of it, this is or might be already possible through vhosts, just without the vhost :P. It's also possible for IRCOps (oper::swhois). The only thing I mentioned was that you currently can only have 1 swhois title, which is something that can/should be changed. I'm not suggesting to anyone to have 20 swhois titles, but more than 1 can be useful. The above is all separate from the /HELPOP command, our 'online' help system, which isn't on any removal list. [*] There could (and are) similar modes which can be considered a 'waste', they are discussed in another bug. |
|
|
The helpop user mode has been removed in 3.4.x because it only added the title "is available for help" in /WHOIS. You can use vhost::swhois to achieve the same effect, which is.. I think.. pretty much what you describe here. I think vhost::swhois has been in Unreal 3.2.x since the beginning. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-04-20 02:40 | Strawberry_Kittens | New Issue | |
| 2008-04-20 03:33 | Strawberry_Kittens | Note Added: 0015275 | |
| 2008-04-20 07:54 | Bricker | Note Added: 0015276 | |
| 2008-04-20 07:54 | Bricker | Status | new => feedback |
| 2008-04-20 20:23 | nate | Status | feedback => assigned |
| 2008-04-20 20:23 | nate | Assigned To | => nate |
| 2008-04-21 01:39 | therock247uk | Note Added: 0015277 | |
| 2008-04-21 14:30 | Jobe | Note Added: 0015278 | |
| 2008-04-21 14:30 | Jobe | Note Edited: 0015278 | |
| 2008-04-21 14:43 | nate | Note Added: 0015279 | |
| 2008-04-21 18:38 | Jobe | Note Added: 0015280 | |
| 2008-04-21 18:39 | Jobe | Note Edited: 0015280 | |
| 2008-04-21 19:37 | nate | Note Added: 0015281 | |
| 2008-04-22 03:45 | Bricker | Note Added: 0015282 | |
| 2008-04-23 13:16 | syzop | Note Added: 0015283 | |
| 2008-10-01 04:29 | Strawberry_Kittens | Note Added: 0015406 | |
| 2013-01-09 09:53 | syzop | Assigned To | nate => |
| 2013-01-09 09:53 | syzop | Status | assigned => acknowledged |
| 2013-01-09 09:53 | syzop | Product Version | 3.3-alpha0 => |
| 2013-01-09 10:19 | katsklaw | Note Added: 0017320 | |
| 2013-01-14 11:59 |
|
Note Added: 0017368 | |
| 2013-01-14 14:49 | syzop | Note Added: 0017373 | |
| 2013-08-12 19:16 | Techman | Note Added: 0017748 | |
| 2013-08-13 17:22 | katsklaw | Note Added: 0017749 | |
| 2013-08-13 17:30 | katsklaw | Note Edited: 0017749 | |
| 2013-08-13 17:32 | katsklaw | Note Edited: 0017749 | |
| 2013-08-14 09:42 | syzop | Note Added: 0017750 | |
| 2014-03-14 01:14 | peterkingalexander | Issue cloned: 0004292 | |
| 2015-07-09 18:48 | syzop | Note Added: 0018434 | |
| 2015-07-09 18:48 | syzop | Status | acknowledged => closed |
| 2015-07-09 18:48 | syzop | Assigned To | => syzop |
| 2015-07-09 18:48 | syzop | Resolution | open => no change required |
