Re: Automatic Update of Org files

From: Mark Elston <m.elston@advantest-ard.com>
To: David Thole <dthole@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: Automatic Update of Org files
Date: Fri, 06 Feb 2009 10:54:05 -0800	[thread overview]
Message-ID: <498C874D.30103@advantest-ard.com> (raw)
In-Reply-To: <b7b383410902060719i40dc3dbas7dfb420716f4b205@mail.gmail.com>

David,

This sound interesting and similar to what I am doing.  I didn't
want to have to parse the Org file but it may be that I have no
choice in the matter.

I may be able to make some of this easier on myself by putting all
(or most) generated information in a block of some kind that allows
me to keep it as text without having to really 'parse' it.  This would
make the 'merge' process simpler.

As for your wishlist items I am not so concerned with the 'postback'
as I am not just looking at my own issues but those in my group as
well.  I won't mark something as done until it has been completed
in TestTrack.

My biggest concern is keeping any notes I add to items I have extracted
from these various sources during an update process.

I tried the org-registry package mentioned by Samuel but it didn't
load and initialize.  I am not sure but I think it may be due to the
fact that my 'org-agenda-files' variable is set to a directory and not
a list of files.

You say you are using Python.  I have used Perl since I found a SOAP
package for Perl and I haven't seen one for Python and I need it for
accessing TestTrack.  I would prefer Python otherwise.

I would be interested in seeing what you have.  It may give me some
ideas.

Mark

* David Thole wrote (on 2/6/2009 7:19 AM):
> Something I've been working on and am continuing to work on is kinda a 
> middleware script like what you're doing.  It's in python now - and have 
> a few who contacted me personally who are interested in this once I get 
> the refactor complete.
> 
> Basically what I've done is try to merge stuff in from our Redmine 
> system here (Redmine is another ticket tracking system).  The workflow I 
> came up with, at least for the script is:
> 
> 1.  Query redmine, get all my assigned issues.
> 2.  Open the org file, read and parse through everything in there 
> (currently it goes for the dates that I have for scheduled, and I want 
> to eventually get it so that all the notes as well as time logging will 
> be captured too.
> 3.  Merge the two sources together (I use two hashed arrays, basically 
> it's something like array[ISSUEID] = array, where the second array 
> contain inforamtion such as the title, project, due date, date 
> scheduled, etc).  I use rules such as that the deadlines are determined 
> in the Redmine system, so that takes priority over my due date - but the 
> date scheduled would be captured, and the state (TODO/DONE/ETC). The 
> status is determined, currently, within Redmine - I haven't figured out 
> a good way yet on dealing with that yet.
> 
> Kinda on my wishlist:
> 
> 1. A "postback" to Redmine, say I update the status to complete, I 
> wouldn't mind if there was a good way to push that information to 
> redmine, using my comments in my ticket to add perhaps - or maybe 
> allowing for a certain type of tag.
> 2. To handle notes, the checked sub-items that can occur, etc.
> 
> It's still a work in progress, but part of my work is to try and allow a 
> more pluggable system so that other ticket management systems can be 
> represented.
> 
> Still working on the refactoring..let me know if this interests you at all.
> 
> -David
> 
> On Thu, Feb 5, 2009 at 5:13 PM, Mark Elston <m.elston@advantest-ard.com 
> <mailto:m.elston@advantest-ard.com>> wrote:
> 
>     Samuel,
> 
>     Thanks for the info.  I will have to digest this and see if it
>     fits.
> 
>     One concern I have with this approach (and I may not have fully
>     grasped what you intended) is that the original source files have
>     the current information like deadlines, etc that I want used
>     when creating my agenda for the week.  If I want more information
>     about the agenda item I will navigate to it and hit <Return> which
>     takes me to the generated Org file.  Once there, I would like to
>     be able to add notes as necessary.
> 
>     Alternatively, I suppose I could navigate to the notes if there is
>     a simple mechanism for this.  I don't really understand all you
>     described below but I will try playing with it and see what comes
>     out.
> 
>     Mark
> 
>     * Samuel Wales wrote (on 2/5/2009 2:40 PM):
> 
>         IIUC, source is not under your complete control.  You need it
>         orgified
>         but also annotated.  There are various annotation mechanisms.  My
>         comments on the remember redesign might be relevant.
> 
>         You could consider going backward.  Have your org file contain links
>         to the read-only stuff.  Put entry IDs in the read-only stuff.
> 
>         Dunno if this helps.
> 
>         Here is something I had lying around:
> 
>         Another feature is to have org-registry show on the mode
>         line when a link points to the current buffer's object (w3m
>         page, file, dired, etc.).  You click on it to go to the org
>         file link.  See my remember suggestions in a previous thred
>         for more re annotations, bookmarks, and registry.
> 
>         I proposed this before:
> 
>         === snip
> 
>         Extension #2 to the bookmark idea.
> 
>         My idea is to always have annotations available for
>         emacs-w3m, dired, files, like org-annotate-file, just with
>         more modes.
> 
>         You can see in the mode line that whatever buffer you are in
>         has an annotation, and you can make an annotation.  You can
>         also go to the annotation.
> 
>         The annotations are stored in an org file anywhere in the
>         hierarchy.  Thus, if you want, annotations on a doctor's web
>         site can be stored in the entry for that doctor that is in
>         your org file.  If you visit that web site from any source,
>         even Google, the mode line says that it is annotated.  Then
>         you can pull up that entry with a command.
> 
>         Likewise with files or dired or whatever.  For example, you
>         can comment org.el or /etc/passwd without having to modify
>         them.
> 
>         Remember code seems a plausible place to arrange for
>         choosing a location and putting a note into it.  Annotations
>         are like bookmarks with text that also go the other
>         direction.  It's natural to combine the idea of a bookmark
>         and the idea of an annotation.
> 
>         You might want the mode line to say "there is bookmark to
>         this (web page, file, etc.)" as one character and "there is
>         a text note about this" as another character.  Thus, if you
>         have annotated a file and the file is unmodified, you will
>         see "-u:--!!" and if you have merely bookmarked the location
>         without commenting on it, then you will see "-u:--!-".
>         === snip
> 
> 
> 
> 
>     _______________________________________________
>     Emacs-orgmode mailing list
>     Remember: use `Reply All' to send replies to the list.
>     Emacs-orgmode@gnu.org <mailto:Emacs-orgmode@gnu.org>
>     http://lists.gnu.org/mailman/listinfo/emacs-orgmode
> 
> 