Use database instead of config.toml calls #12

New Issue

Closed

opened 2019-06-10 09:41:10 +00:00 by b3yond · 3 comments

b3yond commented

2019-06-10 09:41:10 +00:00

Author: @b3yond Posted at: 05.01.2018 12:45

Every toot/tweet/mail should in the end be written to a database, so the bots can communicate with each other over a database, not inside the code, and so everything is trackable and some stuff reversible.

This would also enable to blacklist certain authors.

database city_ticketfrei
- table reports
  - columns:
    - author
    - full_author (full email/username as a reference to block them)
    - report text
    - link to tweet (or tweet object?)
    - link to toot (or toot object?)
    - timestamp of email (or full email object?)

Author: @b3yond Posted at: 05.01.2018 12:45 Every toot/tweet/mail should in the end be written to a database, so the bots can communicate with each other over a database, not inside the code, and so everything is trackable and some stuff reversible. This would also enable to blacklist certain authors. * database city_ticketfrei * table reports * columns: * author * full_author (full email/username as a reference to block them) * report text * link to tweet (or tweet object?) * link to toot (or toot object?) * timestamp of email (or full email object?) *

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

b3yond closed this issue

2019-06-10 09:41:10 +00:00

b3yond commented

2019-06-10 09:41:11 +00:00

Poster

Author: @b3yond Posted at: 07.01.2018 16:03

We took some more time to think through a database concept for multiple cities:

table

columns

user

id
email (login name)
pass_hashed (login passphrase)
active (accounts can be deactivated)

mail

id
user.id (to which user it belongs)
email (e.g. of a mailing list, where reports are sent to)
active (emails can be deactivated)

seen_mails

id
user.id
mail.id
mail_date

twitter_accounts

id
user.id (to which user it belongs)
access_token_key (OAuth2 user key)
access_token_secret (OAuth2 user secret)

twitter_request_tokens

id
user.id (to which user it belongs)
request_token (OAuth2 request token)

seen_tweets

id
user.id (to which user it belongs)
twitter_accounts.id (to which twitter account it belongs)
tweet_id (as which tweet it's stored on twitter.com)

mastodon_instances

id
instance
client_id (OAuth2 app key)
client_secret (OAuth2 app secret)

mastodon_accounts

id
user.id (to which user it belongs)
access_token (OAuth2 user token)
mastodon_instances.id (on which mastodon instance the account is)
active (mastodon can be deactivated)

seen_toots

id
user.id (to which user it belongs)
mastodon_accounts.id (to which mastodon account it belongs)
toot_id (as which toot it's stored on the mastodon instance)

trigger_good

id
user.id (to which user it belongs)
words (string of newline-separated words in the whitelist)

trigger_bad

id
user.id (to which user it belongs)
words (string of newline-separated words in the blacklist)

Author: @b3yond Posted at: 07.01.2018 16:03 We took some more time to think through a database concept for multiple cities: table * columns user * id * email (login name) * pass_hashed (login passphrase) * active (accounts can be deactivated) mail * id * user.id (to which user it belongs) * email (e.g. of a mailing list, where reports are sent to) * active (emails can be deactivated) seen_mails * id * user.id * mail.id * mail_date twitter_accounts * id * user.id (to which user it belongs) * access_token_key (OAuth2 user key) * access_token_secret (OAuth2 user secret) twitter_request_tokens * id * user.id (to which user it belongs) * request_token (OAuth2 request token) seen_tweets * id * user.id (to which user it belongs) * twitter_accounts.id (to which twitter account it belongs) * tweet_id (as which tweet it's stored on twitter.com) mastodon_instances * id * instance * client_id (OAuth2 app key) * client_secret (OAuth2 app secret) mastodon_accounts * id * user.id (to which user it belongs) * access_token (OAuth2 user token) * mastodon_instances.id (on which mastodon instance the account is) * active (mastodon can be deactivated) seen_toots * id * user.id (to which user it belongs) * mastodon_accounts.id (to which mastodon account it belongs) * toot_id (as which toot it's stored on the mastodon instance) trigger_good * id * user.id (to which user it belongs) * words (string of newline-separated words in the whitelist) trigger_bad * id * user.id (to which user it belongs) * words (string of newline-separated words in the blacklist)

b3yond commented

2019-06-10 09:41:11 +00:00

Poster

Author: @b3yond Posted at: 07.01.2018 16:06

The config.toml would be reduced to:

[twitter]
consumer_key
consumer_secret

[logs]
logfile_path

[database]
username
passphrase

[mail]
admin_email
# evtl SMTP credentials for sending mails

Author: @b3yond Posted at: 07.01.2018 16:06 The config.toml would be reduced to: ``` [twitter] consumer_key consumer_secret [logs] logfile_path [database] username passphrase [mail] admin_email # evtl SMTP credentials for sending mails ```

b3yond commented

2019-06-10 09:41:11 +00:00

Poster

Author: @b3yond Posted at: 26.03.2018 19:18

Cool, this is pretty much done. If there is something left, it will be solved by other efforts to get features running. No reason to leave this open.

Author: @b3yond Posted at: 26.03.2018 19:18 Cool, this is pretty much done. If there is something left, it will be solved by other efforts to get features running. No reason to leave this open.