Re: [Concept talk] Org-connector

[Tim Cross <theophilusx@gmail.com>]

Sébastien Gendre <seb@k-7.ch> writes:

> Hello everyone,
>
> I wanted to talk about a concept for Org-mode. For now it's just a
> concept, but maybe it already exist a package that do it.
>
> The concept is called org-connector: It's a package that let you connect
> an Org-mode file with an external tickets or tasks manager and let you
> manage your tasks or tickets from Org-mode.
>
> For example, if your company use Owncloud Deck to manage tasks of the IT
> team:
> 1. Create an Org-mode file
> 2. At the top of the file, add `#+CONNECTOR: owncloud_deck` and
>    `#+CONNECT_TO: https://ourcload.com/url/to/one/deck`
> 3. Run the interactive command `oc-sync`
>
> Then, for every task on the specified Owncloud Deck, you have now an Org
> entry on your file. You can edit them and run the interactive commands
> `oc-sync`, `oc-push` or `oc-pull` to sync, send or receive tasks. If a
> conflict is detected between a local task and a task on the external
> task manager, org-connector ask you if you want to fix it with SMERGE or
> EDIFF.
>
> org-connector package provide all `oc-*` functions, a few back-ends and
> everything needed to declare a new back-ends. Other back-ends can be
> provided by other packages.
>
>
> What do you thing ? Something like that already exist ?
> What kind of feature do you think is needed ?
> How do you think this package must be developed ? What best practice do
> you suggest ? Any advice or idea ?
>

There is a contrib module for jira.

The challenge with your suggestion is that it depends heavily on the API
provided by the remote ticketing system. While you can have specific
connectors to query the remote ticketing system, the 'shape' of data it
returns will vary depending on the system. This would mean at some point
you would need some type of layer to map that into the org file and map
changes in the org file back into something that ticketing system
understands. I think that would be very complex.

So while I think the idea is good in principal, without a standard
'issue' schema or definition, I'm not sure it is practical. However, I
do think we could probably add bits which would make defining a new
ticketing system integration easier.