Skip to content

Supybot Website

Sections
Personal tools
You are here: Home » Supybot Discussion Forums » Developer Forum » A few relatively mechanical things that could be done.
 

 • A few relatively mechanical things that could be done.

Document Actions
Replies: 3   Views: 4976
Up one level
You need to be a registered member to post to this forum. Register now.
Prev topic | Next topic

 • A few relatively mechanical things that could be done.

Posted by jemfinch at 07:16 March 12, 2005
In case you're feeling like hacking, but not feeling creative enough to solve any major issues, I've got a list of mechanical changes that need to take place in Supybot's source code in order to facilitate other changes that are a bit less mechanical.

* src/structures.py needs to be moved to the utils family of modules, in order to make utils entirely free-standing (and thus, make it possible to use it for other projects).

* ircdb.checkCapability needs to take an IrcMsg, rather than a prefix, in order to facilitate a later ability to have one msg run with the capabilities of another (think Observer).

I'll add more to this list as I think of things.

Jeremy
Anonymous
Posts: n/a

 • Re: A few relatively mechanical things that could be done.

Posted by jamessan at 13:56 March 12, 2005
src/structures.py conversion is done.

ircdb.checkCapability conversion is almost done. Just need to determine what to do with checkCapability calls that are being passed a constructed hostmask/hostmask that isn't part of the msg the command received.
Manager
Posts: 104

 • Re: A few relatively mechanical things that could be done.

Posted by jamessan at 17:04 March 12, 2005
So, it turns out the checkCapability thing isn't *quite* as mechanical as we'd hoped. There are situations where we check the capabilities of someone other than who the msg is from. Examples as follows:

Channel.kban:
We construct a banmask and then verify that the banner and bannee aren't both ops.

Channel.alertOps:
We go through all the users in the channel and use their hostmask to check whether they have #channel,op.

Protector.doMode:
When someone {op,halfop,voice}s another user, we use the other user's hostmask to check whether they have the #channel,{op,halfop,voice} capability.

Poll's db.add:
We use user.id to see if the person adding a factoid is an admin. This could easily be worked around, though.

ali's Sshd plugin:
checkCapability is called with the user's name.
Manager
Posts: 104

 • Re: A few relatively mechanical things that could be done.

Posted by jemfinch at 03:13 March 13, 2005
Ok, it seems that the best bet will be to make checkCapability accept multiple mutually-exclusive keyword arguments.

* msg, an IrcMsg. Use the prefix, and alternatively, some tag we specify (so something like Observer can tag the message with 'authenticateAs' or similar)

* prefix (or maybe hostmask would be better)

* id

* username (or just name, whatever's most consistent)

That's the only solution I can think of at the moment.

Jeremy
Anonymous
Posts: n/a

 
Powered by Plone

This site conforms to the following standards: