Multi-Ticketfrei deployment concept discussion #3

New issue

Closed

opened 2019-06-10 09:40:59 +00:00 by b3yond · 1 comment

b3yond commented

2019-06-10 09:40:59 +00:00

Author: @b3yond Posted at: 26.11.2017 13:45

In the long term, it would be nice to have a webservice, where people can create their own ticketfrei bot with a few mouse clicks. This way they don't need an own server to have a ticketfrei bot in their city, and don't have to take effort and responsibility.

Features

a web interface where you can configure your bot, with all the settings in the ticketfrei.cfg
a backend which manages one ticketfrei.py, which handles multiple accounts for different cities and reads their config from a database
OAuth2 for Mastodon and Twitter
A database: concept in #12

Optional Features:

dynamic generation of 1 mailing list per city

User facing frontend

Authentication

The user facing frontend needs an authentication mechanism, so users are able to manage their bot instances.

Users need to be able to change following parameters:

if they want a Twitter bot
- consumer key
- consumer secret
- access token key
- access token secret
- twitter account id (for shutdown messages)
if they want a Mastodon bot
- name of mastodon app
- account's email address
- account passphrase
- mastodon instance
if they want an E-Mail/Mailinglist, where reports are sent to
A list of good words
A list of bad words

Author: @b3yond Posted at: 26.11.2017 13:45 In the long term, it would be nice to have a webservice, where people can create their own ticketfrei bot with a few mouse clicks. This way they don't need an own server to have a ticketfrei bot in their city, and don't have to take effort and responsibility. ## Features * a web interface where you can configure your bot, with all the settings in the ticketfrei.cfg * a backend which manages one ticketfrei.py, which handles multiple accounts for different cities and reads their config from a database * OAuth2 for Mastodon and Twitter * A database: concept in #12 ### Optional Features: * dynamic generation of 1 mailing list per city ## User facing frontend ### Authentication The user facing frontend needs an authentication mechanism, so users are able to manage their bot instances. ### Users need to be able to change following parameters: * if they want a Twitter bot * consumer key * consumer secret * access token key * access token secret * twitter account id (for shutdown messages) * if they want a Mastodon bot * name of mastodon app * account's email address * account passphrase * mastodon instance * if they want an E-Mail/Mailinglist, where reports are sent to * A list of good words * A list of bad words

b3yond added this to the Multi-instance deployment milestone 2019-06-10 09:40:59 +00:00

b3yond closed this issue

2019-06-10 09:40:59 +00:00

b3yond commented

2019-06-10 09:40:59 +00:00

Author

Author: @b3yond Posted at: 15.09.2018 17:36

The concept has advanced quite a bit, but unfortunately it is not documented in this issue. As the milestone is used to track the progress of the multi-deployment branch, this issue has lost its purpose.

Author: @b3yond Posted at: 15.09.2018 17:36 The concept has advanced quite a bit, but unfortunately it is not documented in this issue. As the milestone is used to track the progress of the multi-deployment branch, this issue has lost its purpose.