]> jfr.im git - irc.git/blob - software/RELEASES/ircservices/achurch.org/services/lists/ircservices/2000/000534.html
rename -> *.git
[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices / 2000 / 000534.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
2 <HTML>
3 <HEAD>
4 <TITLE> [IRCServices] ACCESS and *OP
5 </TITLE>
6 <LINK REL="Index" HREF="index.html" >
7 <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20ACCESS%20and%20%2AOP&In-Reply-To=391c4228.01476%40dragonfire.net">
8 <META NAME="robots" CONTENT="index,nofollow">
9 <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
10 <LINK REL="Previous" HREF="000533.html">
11 <LINK REL="Next" HREF="000536.html">
12 </HEAD>
13 <BODY BGCOLOR="#ffffff">
14 <H1>[IRCServices] ACCESS and *OP</H1>
15 <B>Andrew Kempe</B>
16 <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20ACCESS%20and%20%2AOP&In-Reply-To=391c4228.01476%40dragonfire.net"
17 TITLE="[IRCServices] ACCESS and *OP">andrewk at icon.co.za
18 </A><BR>
19 <I>Sat May 13 05:45:44 PDT 2000</I>
20 <P><UL>
21 <LI>Previous message: <A HREF="000533.html">[IRCServices] ACCESS and *OP
22 </A></li>
23 <LI>Next message: <A HREF="000536.html">AW: [IRCServices] ACCESS and *OP
24 </A></li>
25 <LI> <B>Messages sorted by:</B>
26 <a href="date.html#534">[ date ]</a>
27 <a href="thread.html#534">[ thread ]</a>
28 <a href="subject.html#534">[ subject ]</a>
29 <a href="author.html#534">[ author ]</a>
30 </LI>
31 </UL>
32 <HR>
33 <!--beginarticle-->
34 <PRE>&gt;<i> &gt;How would everyone fell if we removed the ACCESS command and replaced it
35 </I>&gt;<i> &gt;with AOP SOP etc? This would simplify things dramatically and I know it
36 </I>&gt;<i> &gt;would affect those people who want very customisable channel access
37 </I>&gt;<i> &gt;levels.
38 </I>
39 [snip]
40
41 &gt;<i> Without touching (yet) the subject of A/S/VOP, I'm very strongly
42 </I>&gt;<i> against the removal of the ACCESS command. While I have to admit part of
43 </I>&gt;<i> that is the fact that I created that system and happen to like it, there
44 </I>&gt;<i> are a couple of other big problems that would crop up:
45 </I>
46 I was just testing the water - I assure everyone that a change like this
47 would not be made without more than a single mail to the mailing list.
48 Having thought about all the comments that have been made I like Andy's idea
49 and it's pretty much inline with what I'd like to implement.
50
51 [snip]
52
53 &gt;<i> My personal preference is to use *OP as an option to the ACCESS ADD
54 </I>&gt;<i> command, and display levels by name in LIST if EXPERT is not set. The
55 </I>&gt;<i> user/Services dialogue would look something like this:
56 </I>&gt;<i>
57 </I>&gt;<i> -&gt; *ChanServ* access #channel add SomeNick sop
58 </I>&gt;<i> -ChanServ- SomeNick added to channel #channel access list as an auto-op.
59 </I>&gt;<i> -&gt; *ChanServ* access #channel list
60 </I>&gt;<i> -ChanServ- Num Level Nick
61 </I>&gt;<i> -ChanServ- 1 SOP MyNick
62 </I>&gt;<i> -ChanServ- 2 AOP NotMyNick
63 </I>&gt;<i> -ChanServ- 3 AOP SomeNick
64 </I>
65 [snip]
66
67 &gt;<i>
68 </I>&gt;<i> Admittedly, the last examples are a bit questionable as they can let
69 </I>&gt;<i> someone with the nick &quot;levels&quot; or &quot;aop&quot; hide from channel lists, but if
70 </I>&gt;<i> that becomes a problem it's easy enough to forbid the nicknames/
71 </I>
72 How about the following...
73
74 Instead of making &quot;SOP&quot; and &quot;AOP&quot; etc access levels, why not just add the
75 following root-level commands: AOP, SOP, VOP. These would work in the same
76 way as DALnet's. e.g.
77
78 /msg chanserv AOP #channel ADD SomeNickName
79 /msg chanserv AOP #channel LIST
80 etc.
81
82 If EXPERT mode is enabled, users will not have access to these commands.
83 They will instead be directed to use the ACCESS command.
84
85 &gt;<i> The EXPERT option might work something like this:
86 </I>&gt;<i>
87 </I>&gt;<i> -&gt; *ChanServ* levels #channel set memo 50
88 </I>&gt;<i> -ChanServ- The EXPERT option must be set to change access level settings.
89 </I>&gt;<i> -&gt; *ChanServ* set #channel expert on
90 </I>&gt;<i> -ChanServ- The EXPERT option for #channel is now active.
91 </I>&gt;<i> -&gt; *ChanServ* levels #channel set memo 50
92 </I>&gt;<i> -ChanServ- Level MEMO on channel #channel changed to 50.
93 </I>
94 [snip]
95
96 If a user tries to disable EXPERT mode for a channel whose ACCESS levels
97 have been modified, they will be asked to reset them to the defaults first.
98
99 &gt;<i> Incidentally, I could see *OP being done as a module which could be
100 </I>&gt;<i> loaded or not at the server operator's choice. (Yes, I will try to get
101 </I>&gt;<i> back onto that module thing RSN...)
102 </I>
103 Andy, please can you mail me your ideas regarding modules.
104
105 Thanks, Andrew
106
107
108 ---------------------------------------------------------------
109 To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A>
110 with &quot;unsubscribe ircservices&quot; in the body, without the quotes.
111
112
113 </PRE>
114
115 <!--endarticle-->
116 <HR>
117 <P><UL>
118 <!--threads-->
119 <LI>Previous message: <A HREF="000533.html">[IRCServices] ACCESS and *OP
120 </A></li>
121 <LI>Next message: <A HREF="000536.html">AW: [IRCServices] ACCESS and *OP
122 </A></li>
123 <LI> <B>Messages sorted by:</B>
124 <a href="date.html#534">[ date ]</a>
125 <a href="thread.html#534">[ thread ]</a>
126 <a href="subject.html#534">[ subject ]</a>
127 <a href="author.html#534">[ author ]</a>
128 </LI>
129 </UL>
130
131 </body></html>