Open tripleee opened 5 years ago
As in, trying to configure privileged users in the bot's code, in chat, or through the command line when the bot is not running?
This is in relation to Andy's request last week. I remember we discussed this back when I originally wanted to add myself to PulseMonitor, but I can't remember what I did then.
https://chat.stackoverflow.com/transcript/message/46852336#46852336
I'm working on a simple command-line hack to create the necessary configuration file.
If there is a way to pivot from unprivileged to privileged via chat, what would that be, and how would that work?
https://github.com/SOBotics/Botpy/blob/master/docs/privilege_system.rst has an incomplete fragment:
A user's privileges can be changed by using the
I guess this should be fixed as well, or instead.
I tried to do this correctly by using the methods in the package, but i ended up having to mock out large parts of ChatExchange, so I gave up on that, and instead landed on the following quick and dirty solution:
#!/usr/bin/env python3
'''
This is a simple command-line tool to create a room configuration file
with the correct fields.
Try running it with something like
PYTHONPATH=. python3 make_room.py 1234 "my test room" 5678 99
where 1234 is the room's identifier and 5678 and 99 are the user id's
of the privileged users you want to add.
This will generate a file like
room_1234_name_my_test_room_privileged_users
which you will need to move to the bot's configuration directory
(typically a dot file in your home directory) to take it into use.
'''
import sys
import pickle
from BotpySE.PrivilegedChatUser import PrivilegedChatUser
from BotpySE.PrivilegeType import PrivilegeType
room = int(sys.argv[1])
room_name = sys.argv[2].replace(' ', '_')
owner = PrivilegeType(1, 'owner')
users = [PrivilegedChatUser(int(x), room, owner) for x in sys.argv[3]:]
with open('room_{}_name_{}_privileged_users'.format(room, room_name),
'wb') as picklefile:
pickle.dump(users, picklefile)
This is probably not robust enough to put into the source tree as a utility for future use, though. Ideally I suppose the code should be refactored to allow you to exercise the methods from ChatRoom
etc, perhaps with a set of simple near-mock replacements for the ChatUser
etc objects that it attempts to traverse.
The above hardcodes privilege level 1 as owner
which contradicts the documentation I linked above, which suggests using privilege level 2 for the owner role. Maybe the script should allow you to pass these values in as parameters, too.
Incidentally, I can't find where the privileged_users
file is actually pulled in - am I missing something?
There are several files which have an import pickle
statement but which never use it for anything as far as I can see. In many places, it looks like the code was originally written to use pickle
but then switched to JSON without removing the import
or occasionally the except
statement for pickle
errors.
I think the use case of the file has been quite misunderstood. The file /home/andy/.andybot/AndyBot_room_196894_data
is automatically created when the need arises (maybe that is quite unclear due to the warning which comes up while the bot is running). Say, for example, a bot without privileges is running; the file will never be created (the code which loads and saves the file is here).
Now, user privileges were designed to be edited through chat; but, to do that, some user needs to have privileges first. Since the RO's often have maximum privileges, you can use this method to grant them the max privs.
Once that method has been used, the file will automatically be created, and then once a new user has been granted privileges through chat, the file will be updated by the bot itself. The only drawback I see in this is that if the owner of the bot is not an RO in the room they are running in, they'll probably have to wait for an RO to grant them privileges (and this also assumes that ROs must be given maximum privileges).
I think a new method to specifically grant privileges to a user in a room should be enough. Once that's done, that user should be able to do everything else. I don't see the need for a command line utility, or have I not understood the issue properly?
(About hardcoding "owner" as 1: the privilege system was designed to be flexible, so you could probably keep an infinite number of privilege levels; the docs just show a specific example)
The use case am attempting to support is running a bot in a room where you are not the owner, and might not have the explicit cooperation of the room owner (not because they disallow bots, but because they have other things to do than help you run a bot, and possibly not the patience to understand a simple request even if you phrase it carefully. Maybe they dislike but tolerate bots, or whatever).
I am vaguely confused by the code -- the file I have in PulseMonitor's configuration is very definitely a pickle
file, whereas the code you pointed to writes JSON. I think JSON would be much preferable, as it can be manipulated in a text editor by anyone who has the foggiest idea about computer-readable text files. Perhaps the simplest fix then would be to make sure the file is indeed always JSON?
(Or am I confused because PulseMonitor does something differently?)
Yes, that is a use case which I perfectly agree with, as I had mentioned in my previous comment. However, I don't see the use of creating a command-line tool to do this. Right now, a line of code can add all room owner to the privilege list; maybe another method to add a specific user to the privilege list should do the trick? Or do you still feel that a full-fledged command-line tool to manipulate the privilege list is necessary?
As far as I see in the code, only a json is written; that json is an encoded pickle, using jsonpickle, but the actual file is surely a json. What's the name of the file you're looking at?
There does not appear to be a convenient way to configure privileged users.
So far, what I have done is to manually manipulate the room's pickle file, but this is clearly less than ideal. If there is no better way to do it currently, at the very least it should be documented (but it's probably less effort to implement a simple command-line tool).