View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003348 | unreal | ircd | public | 2007-05-18 22:58 | 2013-01-09 10:44 |
| Reporter | Shining Phoenix | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Platform | i386 | OS | Linux | OS Version | 2.6.10-1.771_FC2 |
| Product Version | 3.2.6 | ||||
| Summary | 0003348: +mu suggestion | ||||
| Description | Right now, when a nonvoice messages a +mu channel, and their message is not blocked by n or M, ops only see a message "to the whole channel" from IRC. I think it would be better to simply make the server convert "/msg #channel blah" from a nonvoice to a +mu channel to "/msg @#channel blah", i.e. the ops see a message to ops from that user. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Discuss. |
|
|
i think the way it works now is wierd but suitable |
|
|
I like it the way it is now Also, one needs to consider many clients interpret @#channel as a private message from a user to ops so they open a private window with the message. |
|
|
Bugz has a valid point. However, isn't it the client's fault for interpreting @#channel incorrectly? |
|
|
I do NOT need a PM from each nonvoice user in a +mu channel! (Remember that +u designed for chans of hundreds.) Also, RE Phoenix: Please cite the RFC that supports your conclusion that a PM is an incorrect interpretation of /msg @#chan. I like the idea of putting it in channel context, but I cant see any proper way (in the common message display formats) to indicate it was an @msg, and in addition, I have never seen any evidence that the alternate interpretation is incorrect. |
|
|
Jason said: Please cite the RFC that supports your conclusion that a PM is an incorrect interpretation of /msg @#chan. I doubt there is one =\ [13:57:20] <Phoenix> I was about to make a +mu suggestion, but chose to search for other reports on it. There are a lot. Perhaps you guys could make one the parent of the lot and close the rest, so that all +mu bugs and suggestions are in one place? [13:57:42] <satmd> well, I'm only 'reporter' status [13:57:49] <satmd> I doubt I can do that technically [13:58:49] <Phoenix> mm [13:59:07] <Phoenix> Could you pass the message on to someone who can? [13:59:44] <satmd> add a note to one of your bugs ;) [14:00:00] <Phoenix> okay So yeah, I thought having a mother of all +mu reports would be a good idea, instead of half a dozen scattered around the place. Other +mu reports are: http://bugs.unrealircd.org/view.php?id=1750 Temporary or complete invisibility? http://bugs.unrealircd.org/view.php?id=2597 <IRC> blah and You need voice (+v) http://bugs.unrealircd.org/view.php?id=2216 More documentation needed http://bugs.unrealircd.org/view.php?id=2587 You need voice (+v) http://bugs.unrealircd.org/view.php?id=2845 +mu shouldn't hide users from IRCops http://bugs.unrealircd.org/view.php?id=3344 /names and +u http://bugs.unrealircd.org/view.php?id=2906 Asuka +D and +d And now for your viewing pleasure, here's my next +mu suggestion: For most combinations of channel modes, the features of the channel are those of the modes put together. For example, +mN is "nonvoices can't talk" plus "nonops can't nickchange". Very simple. +mu-M is "text from nonvoices goes to ops" plus (u features) plus "bcCfGNST don't affect text from nonvoices". Not very simple. "bcCfGNST don't affect text from nonvoices" is just silly imho. I suggest that we add a new channel mode that does "text from nonvoices goes to ops" only, and make +mu not special anymore, i.e. +mu would then be "nonvoices can't talk" plus (u features) For example, if someone wants "text from nonvoices goes to ops" and "nonops can't CTCP", they could do +<newmode>C. Another example: If they want "text from nonvoices goes to ops" plus (u features) they'd do +<newmode>u Yet another example: +<newmode>M would be "text from nonvoices goes to ops" plus "unregistered nonvoices can't talk" which equals "text from registered nonvoices goes to ops" Another advantage of this new mode is that users would not be forced to mess around with +u to have "text from nonvoices goes to ops". EDIT: Added f to the list of modes screwed by +mu EDIT: Replaces 'messages/notices' with 'text'. |
|
|
+mu has the extra feature for an important reason. +u is designed to be an auditorium. +mu is special because in addition to the auditorium features, people cant interrupt, but the celebrity can still take questions, etc. It's trivial to /ignore IRC (which, being an invalid nick, will never hit an innocent). As for a new mode? It'd be kinda weird to have a mode that only matters when +m/+M is set, and does this odd thing. Sure +mu's behavior is a little weird, but it's rare and if you didn't want it you wouldn't be using it. Best leave things be. |
|
|
Er, the new mode would not require +m or +M to work. |
|
|
No, but as I explained in PM, it would be infeasible to use with +C. +T is just a +m for notices. +M is covered in my statement. What's left? EDIT: Er. Sorry. I misread your statement. Write a module for said mode. I cant really see any huge reason that will get it included in the core, however. |
|
|
I'm not a coder >.> EDIT: Also, it would be more user-friendly to add <newmode> to the /helpop ?chmodes reply instead of a whole paragraph about what +mu does. |
|
|
http://bugs.unrealircd.org/view.php?id=3682 is a duplicate of these issues. 1. Sending text from nonvoices via "IRC" is screwy. 2. Forwarding text from nonvoices to @#channel would not have the desired effect on some clients. 3. Soo...what if text from nonvoices is blocked/stripped by every other mode first, and then simply not sent to halfops and lower? In other words, what a nonvoice says in a celebrity chat channel would appear normally to ops and higher. The disadvantage to this new case is that the ops aren't explicitly shown that nonops can't see what they're seeing. I prefer this case over the previous two. Jason: How does someone new to Unreal IRCd know about the +mu combo? Let's all assume that every IRC user is an experienced coder who has been working with Unreal IRCd for many years... And yet another note: Channel mode m and this new channel mode could be exclusive like p and s, in other words you can't have both m and newmode on, like how you can't have both p and s on. |
|
|
Discussion moved to 0004160 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-05-18 22:58 | Shining Phoenix | New Issue | |
| 2007-05-20 03:56 |
|
Note Added: 0014190 | |
| 2007-05-20 03:56 |
|
Status | new => feedback |
| 2007-05-29 15:37 | White_Magic | Note Added: 0014241 | |
| 2007-05-29 16:23 | Stealth | Note Added: 0014242 | |
| 2008-01-26 07:26 | Shining Phoenix | Note Added: 0014996 | |
| 2008-01-27 01:21 | JasonTik | Note Added: 0015002 | |
| 2008-01-27 01:42 | Shining Phoenix | Note Added: 0015005 | |
| 2008-01-27 01:47 | Shining Phoenix | Note Edited: 0015005 | |
| 2008-01-27 01:50 | JasonTik | Note Added: 0015008 | |
| 2008-01-27 01:58 | Shining Phoenix | Note Added: 0015011 | |
| 2008-01-27 02:13 | JasonTik | Note Added: 0015014 | |
| 2008-01-27 02:14 | JasonTik | Note Edited: 0015014 | |
| 2008-01-29 08:21 | Shining Phoenix | Note Edited: 0015005 | |
| 2008-01-29 08:22 | Shining Phoenix | Note Added: 0015020 | |
| 2008-02-08 22:23 | Shining Phoenix | Note Edited: 0015020 | |
| 2008-04-18 06:47 | Shining Phoenix | Note Edited: 0015005 | |
| 2008-04-25 22:51 | Shining Phoenix | Note Added: 0015286 | |
| 2008-04-25 22:55 | Shining Phoenix | Note Edited: 0015005 | |
| 2008-04-26 07:02 | Bricker | Relationship added | related to 0003682 |
| 2013-01-09 10:41 | syzop | Relationship added | related to 0004160 |
| 2013-01-09 10:44 | syzop | Note Added: 0017332 | |
| 2013-01-09 10:44 | syzop | Status | feedback => closed |
| 2013-01-09 10:44 | syzop | Assigned To | => syzop |
| 2013-01-09 10:44 | syzop | Resolution | open => duplicate |
