#1846 Using the roles feature in the shell, to set admin, seems to not work.
Reporter
Menel
Owner
Nobody
Created
Updated
Stars
★ (1)
Tags
Type-Defect
Priority-Medium
Status-New
Menel
on
Im using trunk nightly build 1869 (2024-02-15, 41a587613a0e)
I tried to set the admins of my prosody server via the shell instead of the command line, just to see if it works.
I started like this:
1: In the prosody config, I disabled all lines starting with "admins = {"
2: I restarted the server.
3: I set admin roles via the shell, and with the shell commands I could confirm my user ( menel@example2.com ) was set as admin.
I made that user admin of the virtualhost example1.com and also for the muc component rooms.example1.com.
4: I restarted prosody again, and could still confirm the admin role for the above hosts via shell command.
5: joining a room at rooms.example1.com did not made my account "owner" of the room and I had apparently no admin privileges in the room.
Secondly using ad-hoc commands on example.com, it did only show the uptime command, I expected "account invite", and "edit blacklist" too, as I could do, as I had set "admins" via the config file before.
So in conclusion, it seems i am not actually admin, neither for the muc component, nor for the virtualhost example2.
6: I set my user again as admin in the config file, then restarted prosody.
7: Now my account ( menel@example2.com ) is again able to use all ad-hoc commands on example.com, and is again owner of rooms at the component rooms.example1.com. It can therefore again change room settings.
Conclusion :
I did expect setting my account as admin via the shell as explained in "3." would give me the same options like mentioned in "7:" , but in fact I could not even see any practical difference between a normal user and an "admin" , set via the shell.
It appears setting an account as admin via the shell does nothing exept *showing* it is admin, if queried the role in the shell.
Menel
on
To clarify, this is an account on virtualhost example 2.com
And the role was set on a virtualhost example1.com and muc component rooms.example1.com
(at one point I wrote the wrong name above in the description)
Unrelated : Found the issue about the doc
https://issues.prosody.im/1771
Im using trunk nightly build 1869 (2024-02-15, 41a587613a0e) I tried to set the admins of my prosody server via the shell instead of the command line, just to see if it works. I started like this: 1: In the prosody config, I disabled all lines starting with "admins = {" 2: I restarted the server. 3: I set admin roles via the shell, and with the shell commands I could confirm my user ( menel@example2.com ) was set as admin. I made that user admin of the virtualhost example1.com and also for the muc component rooms.example1.com. 4: I restarted prosody again, and could still confirm the admin role for the above hosts via shell command. 5: joining a room at rooms.example1.com did not made my account "owner" of the room and I had apparently no admin privileges in the room. Secondly using ad-hoc commands on example.com, it did only show the uptime command, I expected "account invite", and "edit blacklist" too, as I could do, as I had set "admins" via the config file before. So in conclusion, it seems i am not actually admin, neither for the muc component, nor for the virtualhost example2. 6: I set my user again as admin in the config file, then restarted prosody. 7: Now my account ( menel@example2.com ) is again able to use all ad-hoc commands on example.com, and is again owner of rooms at the component rooms.example1.com. It can therefore again change room settings. Conclusion : I did expect setting my account as admin via the shell as explained in "3." would give me the same options like mentioned in "7:" , but in fact I could not even see any practical difference between a normal user and an "admin" , set via the shell. It appears setting an account as admin via the shell does nothing exept *showing* it is admin, if queried the role in the shell.
To clarify, this is an account on virtualhost example 2.com And the role was set on a virtualhost example1.com and muc component rooms.example1.com (at one point I wrote the wrong name above in the description) Unrelated : Found the issue about the doc https://issues.prosody.im/1771