Interface for integration with others services

[pedrommone]

Would be nice if we can receive a status from HipChat or w/e.

• Hipchat
• SMS (Twilio)
• WhatsApp
• Slack
• Email (subscribers).

[manavo]

You mean update a status from HipChat? Or post a notification to HipChat when something changes?

[pedrommone]

Post notifications into HipChat/Send email/SMS/WhatsApp/Facebook. W/e, just make an interface to notify others services.

[pedrommone]

What does "enjoy" means? Haha. Btw, we can make it using events of laravel. Bind an listener event for new issues, closed issues and status updates.

[jbrooksuk]

The enjoy label is something that anybody could mess with. It's unassigned, not necessarily high priority, but if someone gets it in, then awesome.

[jbrooksuk]

@manavo did you decide on how you want third-parties to integrate via the API? Basic Auth is ok for users, but a service should be given a unique token IMHO.

[jbrooksuk]

SMS could be provided with a Twilio adapter.

[pedrommone]

We can use even an Whatsapp API :)

[jbrooksuk]

@pedrommone I've updated your issue to include a task list

[manavo]

Well, do we actually need the 3rd party to authenticate? It's the other way around, we're posting to them.

So we'd need a way to save the auth tokens and endpoints of each service we can notify. But not a way for them to authenticate.

Or have I understood this wrong?

[jbrooksuk]

That's a very good point actually. A services table which stores the required information to connect to each service would be good.

[manavo]

Yep, something along those lines. Just gets annoying because each one has different parameters

[jbrooksuk]

See #44

[Ehesp]

One way of doing it... In the settings table you have enabled/disabled fields for each service... So lets say WhatsApp is enabled.

In your services table, just have a column which is a hashed serialized array of the options for each service. This way, you can create an interface which each service must follow, and one such method could be connect() and you simply pass in each enabled service's details from the table. Something along them lines....

[jbrooksuk]

@Ehesp that's exactly what I did in the pull request I've just made.

[Ehesp]

Great minds....

[jbrooksuk]

👍

[jbrooksuk]

FYI, I've not created a model until you repository changes are merged in.

[jbrooksuk]

Now all we need is an abstract class for handling services, then the connectors are simply making the desired requests.

We can also cheat here as we can use events for when a model is updated. As soon as we see created, saved, updated (or whatever the event names are) we can fire off all activated services. These should be queued up though since they'd be blocking.

[jbrooksuk]

The Service model overrides the properties attribute with a custom getter and setter. It'll automatically handle the JSON encoding and decoding when calling $service->properties - check it out.

[jbrooksuk]

If someone wants to take this up that'd be cool. Otherwise I'll probably push it back till after the First Milestone.