Investigate multi provider support

[freaktechnik]

In bugs #62 and #55 @Mte90 has requested support for additional publishing providers. Apart from the current format restrictions (#68) this also brings with it a few other issues.

First off, currently Tweets are moved from one column to another once they have been published. Should a single issue be able to be published on multiple providers? If yes, that complicates the whole application a lot, unless every issue should be published on every provider. So the choices essentially are:

• Publish each issue on one provider
• Publish every issue on every provider

Depending on this choice, there are further design decisions to make.

Further, Twitter is currently an API client of the core and not just a single source. If other providers were added, how would this affect authentication? How does this affect validation (though that is essentially what #68 should handle)?

This issue should block #62, #68 and #55.

[Mte90]

Probably the best idea is to use label (or something in the title itself like TW/FB) to set the provider and the projects column to publish them.
In that way we can do different messages on different tickets published on different channels or create different sections on every single ticket for a specific message.
So the question is what is the best way for users and dev to adapt the code?
Probably different tickets is the most easy way that improve organization and different users can create new tickets (without admin rights to edit the tickets for add new providers).

[freaktechnik]

Issues can be in multiple projects at once, right? So the best solution would be to have a board per provider, meaning an instance of the service per provider. This would make them independent of each other in handling their state.

I do agree, adding sections for contents for different providers is a good idea.

[Mte90]

Good point and yes the same ticket can be in different projects too.

[Mte90]

I was looking for this to if I can implement the FB support but without that part is impossible :-(
Require an organization of the code, maybe in the meantime can be added and we can see if someone can implement other services.

[freaktechnik]

I have this pretty much laid out in my mind (since I doubt anyone else will attempt to pull apart the existing code). About one thing I'm not sure yet: how the configuration would work. Probably by nesting boards into repos and then having non-github account credentials on a per-board basis. This would even allow multiple twitter accounts in a singe repo!

[Mte90]

I am not sure if it is good to split everything in different report, maybe add settings based for projects? Because issues can be shared between many of them in the same repo and avoiding to split everything in different repository to manage and follow.

[freaktechnik]

Update: I've just successfully tested the first non-Twitter integration: in the bouncyball branch there's now support for Mastodon. The work for it is pretty small, all it required were three files, lib/accounts/mastodon.js, lib/formatters/mastodon.js and lib/validators/mastodon.js as well as adding the config schema for mastodon accounts. The APIs should be generic enough to support most other post based services.

[MichaelKohler]

@freaktechnik I guess this can be closed now?

[freaktechnik]

There's still a few twitter specific things left, like the mentions source. Though I'm not sure if there should be a generic one for that.