Difference between revisions of "Access Levels"

Revision as of 18:07, 27 January 2006

Access levels are assigned both to a user and to an event and serve to limit a user's access to only certain events.

The default access level is 1 for users that are not listed in the Users list. All users can access level 1 events. The higher a user's access level is, the more events that user can access. You can change the default user level to allow unlisted users to access more commands.

Users

In the Users section you can specify a list of users and their access levels using the format:

<level1,level2,...,levelN>:<useraddress>
3,5,6:Dana!dana@staff.quakenet.org

The first level is a general access level, which means that the user can access all levels equal to or less than 3. All the other levels are levels that an event must specifically have to allow a user to access it.

If you want to force the first access level to be a specific level instead of a general access level, you can prefix it with an equal sign.

=3,5,6:Dana!dana@staff.quakenet.org

Now this user has access specifically to level 3, 5, and 6 event and to no other events.

Events

In general, the format of an event is:

on <prefix><level>:<event>:<option/parameters>:<target>:<commands/suffix>:

on ^3:TEXT:hello:?: { msg $nick Hi, $nick }
on 5:TEXT:hello:?:=

With the exception of:

<prefix> <level>:<event>:<target>:<commands>

CTCP 1:HELP:*: { msg $nick No help is available for level 1 users }

For information about the on TEXT above, please read about the = suffix.
The above ctcp command can be accessed by all users because it is a level 1 command. So if a user with nickname goat sends you a /ctcp yournick HELP, your script will send them the above reply.

Only the highest level matching event is triggered for a user.

Named Levels

You can also used named levels which work the same way as a specific level but are easier to understand and read than a number.

friend:Dana!dana@staff.quakenet.org

on @friend:JOIN:#: { msg $nick Welcome $nick ! }

This treats the word friend as a specific access level and matches the user with the event, and because the user is your friend, you welcome them.

Prefixes

You can limit access to an event by specifying special prefixes which determines how an event is processed or triggered by users.

The + prefix

You can limit an event to users with a specific access level by using the + prefix.

10:Dana!dana@staff.quakenet.org

ctcp +5:HELP:*: { msg $nick You have accessed a level +5 event }

The above user can't access this ctcp event even though he has an access level higher than 5, because the event is limited only to level 5 users.

The * prefix

You can allow any user to trigger an event regardless of their access level by using the * prefix.

on *:TEXT:help:#: { msg $nick You have accesed a * level event }

The me: prefix

Makes an event only trigger by yourself or by someone on the same host as yourself. Useful for bots on the same network/computer. Note: Does not work for on TEXT events when the target is a channel, it will however work if you query yourself.

on me:*:JOIN:#: { echo -s I just joined $chan }

This will combine the * prefix for everyone and the me: prefix, you could assign a bot a userlevel that has the same host as yourself if you only want to trigger certain users.

Note: In order to use /haltdef you need to put the ^ sign infront of me:

The ! prefix

You can prevent an event from being triggered if it was initiated by you by using the ! prefix.

on !*:JOIN:#: { echo $chan -t $nick join joined $chan }

You would be unable to access the above event regardless of your access level.

The @ prefix

You can limit events to being executed only when you have Ops on a channel by using the @ prefix.

Blacklist:Dana!dana@staff.quakenet.org

on @Blacklist:JOIN:#: { mode $chan +b $address($nick,3) | kick $chan $nick You are blacklisted. }

When the above user joins a channel you have Ops on, the associated /mode and /kick command will be executed, in this case banning and kicking the user. If you don't have Ops, the event will not trigger.

The & prefix

You can prevent an event from being triggered if a previous script used /halt or /haltdef to halt the display of default text for an event by using the & prefix.

on &1:TEXT:*:?: { echo this event won't trigger if $halted is true }

The $ prefix

Indicates that the matchtext section of a definition contains a Regular_Expression.

on $*:TEXT:m/regular expression/switches:#: { echo message: $1- }

The 'm' and switches are optional. The // are required. If switches are used they must be standard PCRE switches, otherwise the match will fail. You can use switch 'S' to strip control codes from $1-.

Suffixes

Suffixes are used to prevent certain users from access the commands.

The = suffix

You can prevent users with higher access levels from accessing all lower access level events by using the = suffix.

10:Dana!dana@staff.quakenet.org

ctcp 2:HELP:*: { msg $nick You have accessed a level 2 event }
ctcp 5:HELP:*:=

The above user can't access any of these events because the level 5 event prevents him from accessing all HELP events with access levels lower than 5. The only users who can access the above event is someone with user access level 2, 3 or 4.

The ! suffix

You can prevent commands for a certain event level from being processed by using the ! suffix.

ctcp 5:PING:*: { echo PING! }
ctcp 5:*:*:!

The ! at the end of the line tells the remote to halt any further processing of level 5 commands.

Order of definitions

Many of the prefixes and controls are sensitive to numerical order of the definitions. The safest thing is to order your definitions starting with the lowest access levels first and increasing numerically down the list, this makes it easier to keep track of which events should trigger first.

Also See

• auser  ;Used to add a users Access Level.
• guser  ;This acts the same as auser except it looks up a users ident/host via the server.
• flush  ;This clears the remote user list of nickname definitions that are no longer valid.
• ruser  ;Used to remove a user or a users access levels.
• rlevel ;This removes all users from the remote users list with the specified general access level.
• ulist  ;This lists users which have the specified access levels.

NOTES

[16:47] <@Saturn> how did the writer of that note come to that conclusion? [16:47] <@Saturn> i'm using a script that uses on me:^*:.. [16:51] <@Albie> i copied it out of the help file [16:52] <@Saturn> huh? me: isn't documented [16:52] <@Albie> ah well i have teazles [16:58] <@Microbe> This will combine the * prefix for everyone and the me: prefix, you could assign a bot a userlevel that has the same host as yourself if you only want to trigger certain users. [16:58] <@Microbe> I really can't understand that :) [16:59] <@Microbe> and there's no explanation still of why there is that 'extra' :* [16:59] <@Saturn> extra :*  ? [16:59] <@Microbe> on me:*:JOIN:#: { echo -s I just joined $chan } [16:59] <@Microbe> I can't help but considering that as 'extra' :* [16:59] <@Albie> only an extra * [16:59] <@Saturn> so you're still not convinced [16:59] <@Microbe> no matter how you try to convince me :) [16:59] <@Saturn> there is no extra :* [17:00] <@Saturn> on ^*:JOIN:#: { echo -s I just joined $chan } [17:00] <@Saturn> is there an extra :* there ? [17:00] <@Microbe> well if I don't understand it, normal users will definately not understand it either [17:00] <@Saturn> answer the question :p [17:00] <@Microbe> no there isn't :) [17:00] <@Saturn> ok, now substitute "me:" for "^" [17:01] <@Microbe> ok, extra ":" then [17:01] <@Saturn> substitute "me:" for "^" [17:01] <@Albie> me: is the prefix, not me [17:01] <@Albie> .. [17:01] <@Saturn> those three characters [17:01] <@Microbe> the prefix MAKES NO SENSE TO ME :) [17:01] <@Microbe> as all other prefixes are like ! [17:02] <@Microbe> not !: [17:02] <@Albie> maybe thats why its undocumented, so people who dont understand it, wont use it ;p [17:02] <@Saturn> none of the other prefixes contain text, either [17:02] <@Saturn> just look at it as the prefix "me:" and it all makes sense [17:02] <@Saturn> why the prefix is "me:" is another issue [17:03] <@Microbe> well, imo the main point is not to think of it as a user level [17:03] <@Saturn> it sure looks better than "on me*:text:.." anyway [17:03] <@Microbe> what would be the point of me*: ? [17:03] <@Saturn> that would be the prefix "me" instead of "me:" [17:03] <@Albie> :f [17:03] <@Microbe> "me and everyone whose nick is me*" ? [17:03] <@Albie> no because [17:03] <@Saturn> on !*:text [17:03] <@Saturn> on me*:text [17:03] <@Albie> me: is only a host match [17:03] <@Saturn> see? that totally doesnt make sense [17:03] <@Albie> using me: is not the same as if ($me == $nick) [17:04] <@Saturn> it gets worse when you use named userlevels [17:04] <@Saturn> on mefriend:text [17:04] <@Saturn> on me:friend:text <-- MUCH better, although completely pointless [17:04] <@Albie> a userlevel called me? ;p [17:04] <@Microbe> can you make it, Albie? :) [17:04] <@Microbe> guess yes [17:04] <@Albie> i should think so [17:04] <@Saturn> see the : as improvement of readability [17:05] <@Microbe> ok, now summarize this to the wiki [17:05] <@Saturn> just copy&paste this log :p [17:05] <@Microbe> ;)