View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003153 | unreal | ircd | public | 2006-12-20 06:15 | 2013-01-09 10:48 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.3-alpha0 | ||||
| Summary | 0003153: Consider implementing &Channels | ||||
| Description | *CONSIDER* implementing &Channels (local channels) in Unreal33*. Check how much work it is, how it can be done nicely without much mess (macros/subfunctions). Only if it's reasonable, we could implement it. Otherwise, we could decide once and for all not to implement local channels. | ||||
| Additional Information | Basically, any channel command needs to take into account that anything from &channels should not broadcasted to the rest. Additionally, any code like... if (*target == '#') { ...is a channel....} else { ...is a person....} needs to be changed as well... A good way to start on this bug would be to check out /HELPOP ?USERCMDS, check out which are channel commands and check a couple (or all) of them to see how it can be done. Again, adding some macros (or subfunctions) could be a good idea to keep things clean (like an IsChannel() macro, just to name one) This bug was set to PRIVATE to avoid idiot non-technical discussion. | ||||
| 3rd party modules | |||||
| has duplicate | 0003908 | closed | Suggestion for '&' channels |
|
|
.. or implement #channel:servermask? |
|
|
I (and pretty much all users) prefer &channel, really :P |
|
|
One thing.. think about messages from/to &#blah &#blah can mean: a message to chanadmins (&) and higher to channel #blah or &#blah can mean: a normal message to channel &#blah one solution would be to disallow # as the 2nd character of a &channel (so no &#something channels), this fixes all the confusion. I don't see any better alternative that's as simple and effective as that. |
|
|
[quote]one solution would be to disallow # as the 2nd character of a &channel (so no &#something channels), this fixes all the confusion. I don't see any better alternative that's as simple and effective as that.[/quote] We'd also have to disallow & as 2nd character. Else &&blah could mean msg to channel "&&blah" or message to >=admins of "&blah". Minor side note: would implementing this mean we could make can_override possible for local opers (but they'd only have it on &channels, not #channels)? Or a seperate flag, can_local_override for that purpose? Or just not screw with override at all :p ? |
|
|
Or we could still use channel masks, BUT: - A mask cannot contain wildcards - A masked channel exists on all U:Lined servers as well. So you could have a channel #blah:someserver.somenetwork.tld, which is registered, services do work on it, and StatServ sits in there \o/ - Globalops and higher are not kept out of channels by channel masks |
|
|
Ugh. No. I'd rather complicate stuff with local channels than complicate it with channel masks. |
|
|
right aqua |
|
|
What about services? |
|
|
services have nothing to do with &chans, they'll never see them. this is intended behavior. |
|
|
I just wanted to make sure of that =) |
|
|
I was thinking a way for global opers (or netadmins?) to join on remote servers local channels. Is this possible? |
|
|
Should the first joined get +q? It'd make sense |
|
|
>I was thinking a way for global opers (or netadmins?) to join on remote servers local channels. >Is this possible? No. Local channels exist only on the server they are created on. They are not visible on any other server. Hence *LOCAL*. [quote]Should the first joined get +q? It'd make sense[/quote] No it does not. In fact, I see no reason why local channels should be created any differently than nonlocal (apart from not announcing them to other servers). +q is meant to go with services. Services cannot manage local channels. So local channels can never have +q set short of module or operator intervention. It would, however, not be difficult to implement module(s) for ircd-side local channel registration similar to ChanServ. Or a bot that uses joinpartsno + operoverride. On that note, one thing that does need to be addressed is +L: it makes sense to allow &channel to +L #channel or &channel, but absolutely no sense in +L &channel from #channel (as the linked channel would not be the same on all servers that see the link). Granted this could just be left to users realizing that such a thing is useless. |
|
|
[quote]On that note, one thing that does need to be addressed is +L: it makes sense to allow &channel to +L #channel or &channel, but absolutely no sense in +L &channel from #channel (as the linked channel would not be the same on all servers that see the link). Granted this could just be left to users realizing that such a thing is useless.[/quote] I would suggest that both +L &channel from a #channel, and +L #channel from a &channel should be allowed. I could see potential usages for both. No reason to restrict it really. Just like how I see +u being completely useless. But someone has discovered a good use for it. |
|
|
This feature is really too much work for too few people who need it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-12-20 06:15 | syzop | New Issue | |
| 2006-12-20 06:16 | syzop | Additional Information Updated | |
| 2006-12-20 15:02 |
|
Note Added: 0012862 | |
| 2006-12-20 15:05 | syzop | Note Added: 0012863 | |
| 2007-04-27 03:15 |
|
View Status | private => public |
| 2007-04-27 03:15 |
|
Status | new => acknowledged |
| 2007-04-28 07:45 | syzop | Note Added: 0013906 | |
| 2007-04-28 10:49 | aquanight | Note Added: 0013915 | |
| 2007-04-28 17:11 | Shining Phoenix | Note Added: 0013917 | |
| 2007-04-28 17:12 | Shining Phoenix | Note Edited: 0013917 | |
| 2007-04-28 17:25 | Shining Phoenix | Note Edited: 0013917 | |
| 2007-04-28 17:37 | aquanight | Note Added: 0013918 | |
| 2007-04-29 09:01 | syzop | Note Added: 0013922 | |
| 2007-04-29 15:09 | WolfSage | Note Added: 0013925 | |
| 2007-04-29 15:42 | syzop | Note Added: 0013926 | |
| 2007-04-29 17:56 | WolfSage | Note Added: 0013931 | |
| 2007-04-29 18:04 | vonitsanet | Note Added: 0013933 | |
| 2007-04-29 21:38 | Stealth | Note Added: 0013940 | |
| 2007-04-29 22:57 | aquanight | Note Added: 0013941 | |
| 2010-04-15 09:18 | driew | Note Added: 0016067 | |
| 2010-05-24 14:16 | syzop | Relationship added | has duplicate 0003908 |
| 2013-01-09 10:48 | syzop | Note Added: 0017334 | |
| 2013-01-09 10:48 | syzop | Status | acknowledged => closed |
| 2013-01-09 10:48 | syzop | Assigned To | => syzop |
| 2013-01-09 10:48 | syzop | Resolution | open => no change required |
