emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [Concept talk] Org-connector
Date: Wed, 11 Aug 2021 07:49:27 +1000	[thread overview]
Message-ID: <87a6lpezi1.fsf@gmail.com> (raw)
In-Reply-To: <87im0dhvaw.fsf@k-7.ch>

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
> 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. 

  reply	other threads:[~2021-08-10 21:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10 20:57 [Concept talk] Org-connector Sébastien Gendre
2021-08-10 21:49 ` Tim Cross [this message]
2021-08-10 23:21   ` Tom Gillespie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a6lpezi1.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).