UnrealIRCd Bug Tracker
Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003272 [unreal] ircd minor N/A 2007-04-15 12:24 2007-07-17 19:36
Reporter w00t View Status public  
Assigned To
Priority normal Resolution fixed  
Status resolved   Product Version 3.3-alpha0
Summary 0003272: Remove restrictions on NOTICE/PRIVMSG $* for opers.
Description Conversation with Stskeeps:

Robby says:
i want to do another diff, removing restrictions on /notice <mask> for opers - yes, it's spammy, but when they can do the same with services it makes no sense restricting it - also makes announcing a services split difficult ;p
Carsten Munk (Stskeeps) says:
yeah, true
Carsten Munk (Stskeeps) says:
well add that as a bug report + diff as it requires discussion
Additional Information Diff against 3.3 CVS:

Index: src/modules/m_message.c
===================================================================
RCS file: /home/cmunk/ircsystems/cvsroot/unreal/src/modules/Attic/m_message.c,v
retrieving revision 1.1.2.48
diff -u -r1.1.2.48 m_message.c
--- src/modules/m_message.c 16 Dec 2006 16:56:32 -0000 1.1.2.48
+++ src/modules/m_message.c 15 Apr 2007 18:21:53 -0000
@@ -508,24 +508,6 @@
                if ((*nick == '$' || *nick == '#') && (IsAnOper(sptr)
                    || IsULine(sptr)))
                {
- if (IsULine(sptr))
- goto itsokay;
- if (!(s = (char *)rindex(nick, '.')))
- {
- sendto_one(sptr, err_str(ERR_NOTOPLEVEL),
- me.name, parv[0], nick);
- continue;
- }
- while (*++s)
- if (*s == '.' || *s == '*' || *s == '?')
- break;
- if (*s == '*' || *s == '?')
- {
- sendto_one(sptr, err_str(ERR_WILDTOPLEVEL),
- me.name, parv[0], nick);
- continue;
- }
- itsokay:
                        sendto_match_butone(IsServer(cptr) ? cptr : NULL,
                            sptr, nick + 1,
                            (*nick == '#') ? MATCH_HOST :


See also: http://www.rburchell.org/coding/unrealircd/diff-msg-wildcardfix [^]
Tags No tags attached.
3rd party modules
QA Not touched yet by developer
U4: Need for upstream patch No need for upstream InspIRCd patch
U4: Upstream notification of bug Not decided
U4: Contributor working on this None
Attached Files

- Relationships
related to 0003406closed 3.2.7-RC1 NOTICE $* still gives error, but notice goes through anyway 
child of 0003049confirmed 3.3 Suggestions/Features 

-  Notes
(0013390)
Grunt (reporter)
2007-04-15 12:28

I don't see why not. Also, services can split, and how can you apologize to your users when that happens? :P
(0013391)
w00t (reporter)
2007-04-15 12:44

That was my point, yup.
(0013394)
djGrrr (reporter)
2007-04-15 13:17

use wallops and set modes on connect to include +w ?
(0013403)
w00t (reporter)
2007-04-15 16:02

I could walk around a lake to get to a village, or I could swim across it, or I could fly across it, or I could catch a train through a tunnel under it.

Why gline someone when I could akill them, or zline them, or nline them, or spamfilter -u them, etc - each tool fulfils a different purpose.

In general, Services use NOTICE, not WALLOPS - users are going to be acclimatised to recieving NOTICE, not WALLOPS - or perhaps I simply didn't think to have set::modes-on-connect set to include +w before services crashed/other.

None of this is relevant - what is, is removing a useless restriction. I'm aware there are other ways (/notice $*.tld for n tlds on the network), but they all suck.
(0014419)
Shining Phoenix (reporter)
2007-06-26 22:16

In my experience, users wonder wtf just happened when someone does a wallops and then ask how they can. So would prefer /notice $* too.
(0014514)
WolfSage (reporter)
2007-07-17 19:36

Patched by w00t.

- Issue History
Date Modified Username Field Change
2007-04-15 12:24 w00t New Issue
2007-04-15 12:28 Grunt Note Added: 0013390
2007-04-15 12:44 w00t Note Added: 0013391
2007-04-15 13:17 djGrrr Note Added: 0013394
2007-04-15 16:02 w00t Note Added: 0013403
2007-04-15 16:44 tabrisnet Issue Monitored: tabrisnet
2007-04-19 03:02 stskeeps Relationship added child of 0003049
2007-04-19 03:02 stskeeps Status new => confirmed
2007-06-26 15:24 stskeeps Relationship added related to 0003406
2007-06-26 22:16 Shining Phoenix Note Added: 0014419
2007-07-17 19:36 WolfSage Note Added: 0014514
2007-07-17 19:36 WolfSage Status confirmed => resolved
2007-07-17 19:36 WolfSage Resolution open => fixed
2007-07-17 19:36 WolfSage Fixed in Version => 3.2.7


Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker