Management of vote permissions

[CrsiX]

How should we manage vote permissions? As a matter of fact, only internals should be allowed to vote on payment requests of course. And you can't vote on your own payment request. Additionally, internals must have a flag permission set to True, the default is False if omitted during account creation.

So, we need to find ways how to manage the following tasks:

• An internal user wants to get vote permissions (may require community approval?).
• An internal user should loose the vote permissions (may require community approval?).
• If no one had vote permissions first, who should get this permissions at first?

In order to handle this cases, the bot admin could use the CLI if we added the feature to support this. But this is no user-friendly way, so this is discouraged.

We might consider to give every user the permissions to vote by default and only remove the permissions on abuse.

[CrsiX]

The third problem should be solved by #61 as soon as the manage feature has been implemented.

[CrsiX]

The first and second problem should indeed be solved by some form of community approval. The majority of the community must permit someone vote permissions (of course, the other way round must also work). However, is it requrired to have vote permissions on a vote about giving/taking some else's voting permissions?

[CrsiX]

After some discussions, here are the updated "guidelines":

• Vote permissions can only be given to internal users.
• Giving and taking vote permissions requires community approval using the same rules as for payment requests with /pay. However, the configuration might use other attributes for this purpose (e.g. not payment-denial but rather voting-denial).
• By default, no internal user has voting permissions.
• To vote about one of those "voting requests", you need the permissions to vote, of course (same rule as for payment requests).
• The first few users that are required to vote on the community approval stuff must be set up manually on the command-line (see WIP: Implemented a whole new command-line interface #61) or by querying the database directly (only as long as WIP: Implemented a whole new command-line interface #61 is not merged!).

There will be a new command /voting [user] that requires permission level 2 (internal user). In case the parameter user is not present, the author of the command is assumed as user.
The bot will send out a vote request to the internal group (because the command can only be issued from there). All members will be able to vote using the CallbackQuery feature of inline keyboards. This requires two to three buttons: YES, NO and the optional ABSTAIN. (Note that those words may be changed later on.) It might be a cool idea to use the built-in poll feature of Telegram as well (telegram.Poll).

Two more questions that might need further discussion:

1. Should the approval process to give or take permissions be a secret vote, i.e. should the other community members be able to see what someone voted for?
2. If a user has the permissions and it was requested to remove his/her permissions, is this user allowed to vote on the request (because he/she is the "target" of the request)?

[CrsiX]

This issue is pretty old but still accurate in some points. Membership polls have been implemented in the server code and should be fully functional™. Applications are now able to implement the respective API.

Therefore, to finally close this issue, the following tasks need to be addressed (regarding only the command-line interface, since everything else works):

• Add command-line features to list users
• Add command-line features to add users
• Add command-line features to manage user flags (external as well as permission)