org-jira.el

org-jira.el

[Bao Haojun]

Hi, all

I have implemented org-jira.el, bringing org-mode and Jira system
together.

Wrote a Wiki page for it on emacswiki:
http://www.emacswiki.org/emacs/OrgJiraMode

Hope somebody find it useful, if he/she is also using Jira and loves
org-mode.

Re: org-jira.el... and Org conventions (Bastien, Carsten and all)

[Sebastien Vauban]

Hi Bao,

"Bao Haojun" wrote:
> I have implemented org-jira.el, bringing org-mode and Jira system
> together.
>
> Wrote a Wiki page for it on emacswiki:
> http://www.emacswiki.org/emacs/OrgJiraMode
>
> Hope somebody find it useful, if he/she is also using Jira and loves
> org-mode.

I had never heard of Jira, but your work definitely looks very promising.
IMHO, it should be compared with org-x and its extension to Redmine, among
others.

But this triggers, for me, another "concern" which is the very wide variety of
ways to define the same thing.

Let's just take how we represent who's gonna be assigned a task:

- In most examples we see on the Net (or in the Org manual), people use tags
  with person names (or abbreviations).

- In your case, you mirror what's done in Jira (I guess) and you introduce a
  property "Assignee".

- In Org issues (http://orgmode.org/worg/org-issues.html), some tasks are
  given a property "Who" to indicate who has to work on them.

- In tasks used for interacting with TaskJuggler, one uses a "Resource-Id"
  property.

- Still another approach is used by Juan Reyero in his advertised "Org-mode
  tricks for team management" (see [1]), using a combination of TODO todo
  keywords for his own tasks, and TASK keywords for tasks assigned to members
  of his team.

All of this makes it hard to have one independent Org file, and be able to
cooperate with external tools (like Jira, Redmine, TaskJuggler and others) on
a "on demand" approach.

You want a Gantt chart?  You need to add (or rename) "Resource-Id" properties.

Now, you would like a Web-based Bug Tracking system?  Too bad: you need to add
(or rename) properties "Assignee" or ...

So, my point is: wouldn't it be better if we proposed standard properties in
Org (in the manual), and implemented mappings in the Org "integration"
packages (org-jira, org-taskjuggler, org-redmine and the like)?

So, say for example that, from now on, it's more standard in Org to use
"Assignee" (or anything else) for representing who's assigned a task, and have
every package map the property "Assignee" to whatever keyword used in external
tools for representing that concept?

If we do such,

- we _do not impose anything_ (everybody is still free to represent this task
  the way he wants, be it properties or tags)

- we ensure an easy transition to use any external tool for those that used
  the "to be defined" standard properties.

Best regards,
  Seb

Footnotes:

[1] http://juanreyero.com/article/emacs/org-teams.html

-- 
Sebastien Vauban

Re: org-jira.el... and Org conventions (Bastien, Carsten and all)

[Bao Haojun]

Hi Sebastien, 

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Bao,
>
> "Bao Haojun" wrote:
>> I have implemented org-jira.el, bringing org-mode and Jira system
>> together.
>>
>> Wrote a Wiki page for it on emacswiki:
>> http://www.emacswiki.org/emacs/OrgJiraMode
>>
>> Hope somebody find it useful, if he/she is also using Jira and loves
>> org-mode.
>
> I had never heard of Jira, but your work definitely looks very promising.
> IMHO, it should be compared with org-x and its extension to Redmine, among
> others.

Thanks for the praise! Jira is a "commercial" issue tracker, but it also
seems to be OSS friendly (by allowing OSS community to use the software
for free; Apache is using it, see http://wiki.apache.org/general/ApacheJira).

Likewise I had not heard of org-x and Redmine, thanks for letting me know.
>
> But this triggers, for me, another "concern" which is the very wide variety of
> ways to define the same thing.

> ...

> So, my point is: wouldn't it be better if we proposed standard properties in
> Org (in the manual), and implemented mappings in the Org "integration"
> packages (org-jira, org-taskjuggler, org-redmine and the like)?
>
> So, say for example that, from now on, it's more standard in Org to use
> "Assignee" (or anything else) for representing who's assigned a task, and have
> every package map the property "Assignee" to whatever keyword used in external
> tools for representing that concept?

I can see your point, that standard thing is good, if it's already here,
I will definitely try comply to them.

But your worrying people need to transition from one system such as
org-jira to another such as org-x, I think they are not very
often. Because if it happens, it would mean that the COMPANY/COMMUNITY
has decided to switch from Jira to Redmine, can you imagine how often
that can be?

Besides, even if that really happens, it would also mean the
COMPANY/COMMUNITY has got a way to transition from Jira to Redmine, so
there would have already been a way to transit from org-jira to org-x:
org-jira -> Jira -> Redmine -> org-x (and vice versa).

So my point is, if someone try to make transition easy, they should do
it on the company level, such as from Jira to Redmine. Org mode feels
kind of personal to me, and I feel good enough to be able to sync
between company issue tracking system and my org-mode, no need for it to
be able to transit to another issue tracking system's org-mode.

Best Regards,
  Bao Haojun

Re: org-jira.el... and Org conventions (Bastien, Carsten and all)

[Sebastien Vauban]

Hi Bao,

"Bao Haojun" wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> "Bao Haojun" wrote:
>>> I have implemented org-jira.el, bringing org-mode and Jira system
>>> together.
>>>
>>> Wrote a Wiki page for it on emacswiki:
>>> http://www.emacswiki.org/emacs/OrgJiraMode
>>>
>>> Hope somebody find it useful, if he/she is also using Jira and loves
>>> org-mode.
>>
>> I had never heard of Jira, but your work definitely looks very promising.
>> IMHO, it should be compared with org-x and its extension to Redmine, among
>> others.
>
> Thanks for the praise! Jira is a "commercial" issue tracker, but it also
> seems to be OSS friendly (by allowing OSS community to use the software for
> free; Apache is using it, see http://wiki.apache.org/general/ApacheJira).
>
> Likewise I had not heard of org-x and Redmine, thanks for letting me know.
>
>> But this triggers, for me, another "concern" which is the very wide variety
>> of ways to define the same thing.
>>
>> So, my point is: wouldn't it be better if we proposed standard properties
>> in Org (in the manual), and implemented mappings in the Org "integration"
>> packages (org-jira, org-taskjuggler, org-redmine and the like)?
>>
>> So, say for example that, from now on, it's more standard in Org to use
>> "Assignee" (or anything else) for representing who's assigned a task, and
>> have every package map the property "Assignee" to whatever keyword used in
>> external tools for representing that concept?
>
> I can see your point, that standard thing is good, if it's already here, I
> will definitely try comply to them.

Thanks for your proposition.

I will let others express their own meaning, but, seeing your answer, I wanted
to recalibrate what I expressed.

> But your worrying people need to transition from one system such as org-jira
> to another such as org-x, I think they are not very often. Because if it
> happens, it would mean that the COMPANY/COMMUNITY has decided to switch from
> Jira to Redmine, can you imagine how often that can be?
>
> Besides, even if that really happens, it would also mean the
> COMPANY/COMMUNITY has got a way to transition from Jira to Redmine, so there
> would have already been a way to transit from org-jira to org-x: org-jira ->
> Jira -> Redmine -> org-x (and vice versa).
>
> So my point is, if someone try to make transition easy, they should do it on
> the company level, such as from Jira to Redmine. Org mode feels kind of
> personal to me, and I feel good enough to be able to sync between company
> issue tracking system and my org-mode, no need for it to be able to transit
> to another issue tracking system's org-mode.

You're right we could understand my proposition as being an easier way to
change between bug tracking systems. But not only that.

I gave the example of Task Juggler: wouldn't it be nice to be able -- at any
point in time -- to generate a dependency graph through Task Juggler, while
being able (at the same time, without touching anything) to get the tasks
maintained in, let's say, Redmine (which does not offer a Gantt chart
functionality IIRC)?

So, the question is not really about switching from one system to another, but
more about using 2 (or more) systems in parallel... While the former may be a
rare occurrence in a project, I guess the latter is more a common wish.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: org-jira.el... and Org conventions (Bastien, Carsten and all)

[Allen S. Rout]

On 01/03/2012 10:53 AM, Bao Haojun wrote:

>
> So my point is, if someone try to make transition easy, they should do
> it on the company level, such as from Jira to Redmine. Org mode feels
> kind of personal to me, and I feel good enough to be able to sync
> between company issue tracking system and my org-mode, no need for it to
> be able to transit to another issue tracking system's org-mode.


It shouldn't be necessary for the org-mode user to learn 'How Haojun 
thinks about ticket systems' to use jira, and then also learn 'how 
[someone] thinks about ticket systems' to then use the (imagined?) TRAC 
integration.

It should be enough to understand 'How org-mode thinks about ticket 
systems'.   Unfortunately, in order to do this, it is necessary for 
org-mode to have an opinon. :)   Which it doesn't, yet.



- Allen S. Rout

Re: org-jira.el... and Org conventions (Bastien, Carsten and all)

[Bastien]

"Allen S. Rout" <asr@ufl.edu> writes:

> It should be enough to understand 'How org-mode thinks about ticket
> systems'.   Unfortunately, in order to do this, it is necessary for
> org-mode to have an opinon. :)   Which it doesn't, yet.

<yoda_mode>

  Org Mode does not think about things, it achieves them.

</yoda_mode>

-- 
 Bastien

Re: org-jira.el... and Org conventions (Bastien, Carsten and all)

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> "Allen S. Rout" <asr@ufl.edu> writes:
> 
> > It should be enough to understand 'How org-mode thinks about ticket
> > systems'.   Unfortunately, in order to do this, it is necessary for
> > org-mode to have an opinon. :)   Which it doesn't, yet.
> 
> <yoda_mode>
> 
>   Org Mode does not think about things, it achieves them.
> 
> </yoda_mode>
> 

You obviously meant

<yoda_mode>

  things about Org Mode think does not, achieves them it.

</yoda_mode>

:-)

Standard property proposal (was: org-jira.el... and Org conventions (Bastien, Carsten and all))

[Karl Voit]

Hi!

* Sebastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:
>
> But this triggers, for me, another "concern" which is the very wide variety of
> ways to define the same thing.
[...]

Totally agree to that.

> So, my point is: wouldn't it be better if we proposed standard properties in
> Org (in the manual), and implemented mappings in the Org "integration"
> packages (org-jira, org-taskjuggler, org-redmine and the like)?
>
> So, say for example that, from now on, it's more standard in Org to use
> "Assignee" (or anything else) for representing who's assigned a task, and have
> every package map the property "Assignee" to whatever keyword used in external
> tools for representing that concept?

I'd say that this issue is a HUGE one for the future of Org-mode. It
is ubiquitous to users all over. I myself had troubles adopting
org-contacts[1][2] because of only one single email property defined. 

When I started developing software that *massively* converts user
data into Org-mode format[3], I felt this strange itch, whether my
property definitions are well chosen or not ...

I *love* the fact that Org-mode is so lightweight and so heavy the
same time - just as the user wants it.

But using conventions also has some drawbacks. Whenever someone
wants to define a certain format with properties for example, she
has to define her own way. If there is an Org-mode extension using
similar data, users woun't notice until some data show up on this
list and another Org-mode user is adding a hint.

So a free-to-use recommendation list of standard properties would be
*very* fine.

Part of my research work is in the field of information architecture
for personal information management. If I can be of any help in some
kind of discussion and definition process, I'd be glad.

[1] http://article.gmane.org/gmane.emacs.orgmode/47478
[2] http://article.gmane.org/gmane.emacs.orgmode/45347
[3] https://github.com/novoid/Memacs

-- 
Karl Voit

Re: Standard property proposal

[Bastien]

Hi all,

Karl Voit <devnull@Karl-Voit.at> writes:

> So a free-to-use recommendation list of standard properties would be
> *very* fine.

Agreed.  Please feel free to start it on Worg -- that's exactly 
the kind of documentation where we need several contributions.

On top of such recommendations, we could have a notion of 
"property name alias" -- if Alice uses "Assignee" while Bob
uses "Owner", they can share an alias Assignee--Bob and read
eachothers files transparently.

Same for importing/exporting date into/from Org files.

My 2 cents,

-- 
 Bastien

Re: org-jira.el

[Marc Spitzer]

This will be very handy.

Thanks,

marc

On Mon, Jan 2, 2012 at 7:08 AM, Bao Haojun <baohaojun@gmail.com> wrote:
> Hi, all
>
> I have implemented org-jira.el, bringing org-mode and Jira system
> together.
>
> Wrote a Wiki page for it on emacswiki:
> http://www.emacswiki.org/emacs/OrgJiraMode
>
> Hope somebody find it useful, if he/she is also using Jira and loves
> org-mode.
>
>
>



-- 
Freedom is nothing but a chance to be better.
--Albert Camus

 The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher

Do the arithmetic or be doomed to talk nonsense.
--John McCarthy

Re: org-jira.el

[Bastien]

Hi Bao,

"Bao Haojun" <baohaojun@gmail.com> writes:

> I have implemented org-jira.el, bringing org-mode and Jira system
> together.

Thanks!  I wish I could test it, but I don't have access to a Jira 
tracking system.

> Wrote a Wiki page for it on emacswiki:
> http://www.emacswiki.org/emacs/OrgJiraMode

Since your org-jira.el relies on jira2.el, maybe you could rename
it to org-jira2.el?  Note that we have contrib/lisp/org-jira.el 
already, avoiding names conflict would be great.

Just a suggestion.

All best,

-- 
 Bastien

Re: org-jira.el

[Nick Dokos]

Bastien <bzg@altern.org> wrote:

> Hi Bao,
> 
> "Bao Haojun" <baohaojun@gmail.com> writes:
> 
> > I have implemented org-jira.el, bringing org-mode and Jira system
> > together.
> 
> Thanks!  I wish I could test it, but I don't have access to a Jira 
> tracking system.
> 
> > Wrote a Wiki page for it on emacswiki:
> > http://www.emacswiki.org/emacs/OrgJiraMode
> 
> Since your org-jira.el relies on jira2.el, maybe you could rename
> it to org-jira2.el?  Note that we have contrib/lisp/org-jira.el 
> already, avoiding names conflict would be great.
> 

The current contrib/lisp/org-jira.el is pretty trivial: it just defines
a jira link type, so maybe it can be integrated into the new org-jira.el,
instead of having two of them lying around.

Nick

Re: org-jira.el

[Bastien]

Nick Dokos <nicholas.dokos@hp.com> writes:

> The current contrib/lisp/org-jira.el is pretty trivial: it just defines
> a jira link type, so maybe it can be integrated into the new org-jira.el,
> instead of having two of them lying around.

Agreed.  In the same vein, perhaps jira2.el and jira.el could be merged
into one single library.

-- 
 Bastien

Re: org-jira.el

[Bao Haojun]

Bastien <bzg@altern.org> writes:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> The current contrib/lisp/org-jira.el is pretty trivial: it just defines
>> a jira link type, so maybe it can be integrated into the new org-jira.el,
>> instead of having two of them lying around.
>
> Agreed.  In the same vein, perhaps jira2.el and jira.el could be merged
> into one single library.

Agreed. I have not looked into org-mode source code yet, so do not know
about contrib/lisp/org-jira.el, but I think it is the same one on
emacswiki, which has been abandoned by its author. So, it will be
trivial to merge its functionality.

You are also right that jira2.el and jira.el can be merged,
theoretically. The jira2.el, as a library, is a superset of jira.el in
terms of functionality, since jira2.el uses soap, while jira.el uses
xml-rpc; and soap is better supported by jira than xml-rpc.

The difficulty lies in that jira.el is also a major mode (in addition to
providing the library for the major mode). To make sure backward
compatible will require some effort. Jira2.el, OTOH, has stopped to be a
major mode, and only provided library for (the new) org-jira.el.

Anyway, I will try to update jira.el and contact the original author to
see if he agrees.

Re: org-jira.el

[Jonathan Arkell]

Wow Bao!  I am just checking out your org-jira2 project right now...

Your thing was what my thing (contrib/lisp/org-jira.el) was going to
become when I got the time... Then I got put on a project that didn't use
Jira, and abandoned it (as mentioned earlier).

So yea, Bastien, Bao, and anyone else for that matter, go ahead and do
what you like with that trivial piece of code. Rename it, delete it, fold
it into the new library.


Ironically enough, years later, I am back on a project that does use
Jira.. :)
__________________________________


Jonathan Arkell
Tech Lead
Inspired By Drum & Bass, Scheme, Kawaii

p. 403.206.4377
402 -- 11th Ave SE
Calgary, AB, Canada T2G 0Y4

jonathana@criticalmass.com
criticalmass.com









On 5/01/12 7:42 AM, "Bao Haojun" <baohaojun@gmail.com> wrote:

>Bastien <bzg@altern.org> writes:
>
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>>
>>> The current contrib/lisp/org-jira.el is pretty trivial: it just defines
>>> a jira link type, so maybe it can be integrated into the new
>>>org-jira.el,
>>> instead of having two of them lying around.
>>
>> Agreed.  In the same vein, perhaps jira2.el and jira.el could be merged
>> into one single library.
>
>Agreed. I have not looked into org-mode source code yet, so do not know
>about contrib/lisp/org-jira.el, but I think it is the same one on
>emacswiki, which has been abandoned by its author. So, it will be
>trivial to merge its functionality.
>
>You are also right that jira2.el and jira.el can be merged,
>theoretically. The jira2.el, as a library, is a superset of jira.el in
>terms of functionality, since jira2.el uses soap, while jira.el uses
>xml-rpc; and soap is better supported by jira than xml-rpc.
>
>The difficulty lies in that jira.el is also a major mode (in addition to
>providing the library for the major mode). To make sure backward
>compatible will require some effort. Jira2.el, OTOH, has stopped to be a
>major mode, and only provided library for (the new) org-jira.el.
>
>Anyway, I will try to update jira.el and contact the original author to
>see if he agrees.
>
>


The information contained in this message is confidential. It is intended to be read only by the individual or entity named above or their designee. If the reader of this message is not the intended recipient, you are hereby notified that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message.

Re: org-jira.el

[Bao Haojun]

Thank you!

Jonathan Arkell <jonathana@criticalmass.com> writes:

> Wow Bao!  I am just checking out your org-jira2 project right now...
>
> Your thing was what my thing (contrib/lisp/org-jira.el) was going to
> become when I got the time... Then I got put on a project that didn't use
> Jira, and abandoned it (as mentioned earlier).
>
> So yea, Bastien, Bao, and anyone else for that matter, go ahead and do
> what you like with that trivial piece of code. Rename it, delete it, fold
> it into the new library.
>
>
> Ironically enough, years later, I am back on a project that does use
> Jira.. :)
> __________________________________
>
>
> Jonathan Arkell
> Tech Lead
> Inspired By Drum & Bass, Scheme, Kawaii
>
> p. 403.206.4377
> 402 -- 11th Ave SE
> Calgary, AB, Canada T2G 0Y4
>
> jonathana@criticalmass.com
> criticalmass.com
>
>
>
>
>
>
>
>
>
> On 5/01/12 7:42 AM, "Bao Haojun" <baohaojun@gmail.com> wrote:
>
>>Bastien <bzg@altern.org> writes:
>>
>>> Nick Dokos <nicholas.dokos@hp.com> writes:
>>>
>>>> The current contrib/lisp/org-jira.el is pretty trivial: it just defines
>>>> a jira link type, so maybe it can be integrated into the new
>>>>org-jira.el,
>>>> instead of having two of them lying around.
>>>
>>> Agreed.  In the same vein, perhaps jira2.el and jira.el could be merged
>>> into one single library.
>>
>>Agreed. I have not looked into org-mode source code yet, so do not know
>>about contrib/lisp/org-jira.el, but I think it is the same one on
>>emacswiki, which has been abandoned by its author. So, it will be
>>trivial to merge its functionality.
>>
>>You are also right that jira2.el and jira.el can be merged,
>>theoretically. The jira2.el, as a library, is a superset of jira.el in
>>terms of functionality, since jira2.el uses soap, while jira.el uses
>>xml-rpc; and soap is better supported by jira than xml-rpc.
>>
>>The difficulty lies in that jira.el is also a major mode (in addition to
>>providing the library for the major mode). To make sure backward
>>compatible will require some effort. Jira2.el, OTOH, has stopped to be a
>>major mode, and only provided library for (the new) org-jira.el.
>>
>>Anyway, I will try to update jira.el and contact the original author to
>>see if he agrees.
>>
>>
>
>
> The information contained in this message is confidential. It is
> intended to be read only by the individual or entity named above or
> their designee. If the reader of this message is not the intended
> recipient, you are hereby notified that any distribution of this
> message, in any form, is strictly prohibited. If you have received
> this message in error, please immediately notify the sender and delete
> or destroy any copy of this message.

Re: org-jira.el

[Bao Haojun]

Hi Jonathan,
Jonathan Arkell <jonathana@criticalmass.com> writes:

> Wow Bao!  I am just checking out your org-jira2 project right now...
>
> Your thing was what my thing (contrib/lisp/org-jira.el) was going to
> become when I got the time... Then I got put on a project that didn't use
> Jira, and abandoned it (as mentioned earlier).
>
> So yea, Bastien, Bao, and anyone else for that matter, go ahead and do
> what you like with that trivial piece of code. Rename it, delete it, fold
> it into the new library.
>

I have merged it. Now the jira link type will be opened by
org-jira-mode, jumping (retieving first if not done already) to the org
heading tracking the issue specified in the link.

By the way, do you mind if I keep using the name org-jira.el? org-jira2
is not a good name just as jira2 is not.

Thanks.
-- 
All the best

 Bao Haojun

Re: org-jira.el

[Richard Riley]

Bastien <bzg@altern.org> writes:

> Hi Bao,
>
> "Bao Haojun" <baohaojun@gmail.com> writes:
>
>> I have implemented org-jira.el, bringing org-mode and Jira system
>> together.
>
> Thanks!  I wish I could test it, but I don't have access to a Jira 
> tracking system.
>
>> Wrote a Wiki page for it on emacswiki:
>> http://www.emacswiki.org/emacs/OrgJiraMode
>
> Since your org-jira.el relies on jira2.el, maybe you could rename
> it to org-jira2.el?  Note that we have contrib/lisp/org-jira.el 
> already, avoiding names conflict would be great.
>
> Just a suggestion.
>
> All best,


Adding "2" to a name leads to hellish issues in the future with regards
to peoples understanding of which is the newest. js-mode is a great
example of this and the numerous "2" versions lurking around.

Possibly clean the code and include org-jira if possible and name it
"jira+" or even better replace the + with something relevant to why it
actually exists above and beyond the existing code.

Just a suggestion ;)

Re: org-jira.el

[Mehul Sanghvi]

On Wed, Jan 4, 2012 at 13:36, Richard Riley <rileyrg@gmail.com> wrote:
> Bastien <bzg@altern.org> writes:
>
>> Hi Bao,
>>
>> "Bao Haojun" <baohaojun@gmail.com> writes:
>>
>>> I have implemented org-jira.el, bringing org-mode and Jira system
>>> together.
>>
>> Thanks!  I wish I could test it, but I don't have access to a Jira
>> tracking system.
>>
>>> Wrote a Wiki page for it on emacswiki:
>>> http://www.emacswiki.org/emacs/OrgJiraMode
>>
>> Since your org-jira.el relies on jira2.el, maybe you could rename
>> it to org-jira2.el?  Note that we have contrib/lisp/org-jira.el
>> already, avoiding names conflict would be great.
>>
>> Just a suggestion.
>>
>> All best,
>
>
> Adding "2" to a name leads to hellish issues in the future with regards
> to peoples understanding of which is the newest. js-mode is a great
> example of this and the numerous "2" versions lurking around.
>
> Possibly clean the code and include org-jira if possible and name it
> "jira+" or even better replace the + with something relevant to why it
> actually exists above and beyond the existing code.
>
> Just a suggestion ;)
>
>
>


I agree with Richard, especially with regards to js-mode.

Merging the contrib/lisp/org-jira.el with the new org-jira.el might be
a good idea
if the contrib one is just implementing a jira link.

We use Jira at my work, so when I get back to the office I plan to try out both
and see what may work.

This will be great for keeping track of issues.  I already use Emacs
to edit the confluence
wiki that we have, now I can do the same with Jira issues as well.


-- 
Mehul N. Sanghvi
email: mehul.sanghvi@gmail.com

Re: org-jira.el

[Bastien]

Richard Riley <rileyrg@gmail.com> writes:

> Adding "2" to a name leads to hellish issues in the future with regards
> to peoples understanding of which is the newest. js-mode is a great
> example of this and the numerous "2" versions lurking around.
>
> Possibly clean the code and include org-jira if possible and name it
> "jira+" or even better replace the + with something relevant to why it
> actually exists above and beyond the existing code.
>
> Just a suggestion ;)

Agreed.  Less is more!

-- 
 Bastien

Re: org-jira.el

[OSiUX]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

El lun, 02 ene 2012, Bao Haojun decía:

> Hi, all
> 
> I have implemented org-jira.el, bringing org-mode and Jira system
> together.
> 
> Wrote a Wiki page for it on emacswiki:
> http://www.emacswiki.org/emacs/OrgJiraMode
> 
> Hope somebody find it useful, if he/she is also using Jira and loves
> org-mode.
> 
> 
> 

after running Mx jira2-login, I get the following error:

    Symbol's function definition is void: auth-source-search

howto configure login?

-- 

::

  Osiris Alejandro Gomez (OSiUX) osiux@osiux.com.ar
  AA70 93FD B6EF EB42 6920 7530 A799 B226 74C8 A3FE
  http://osiux.com http://wiki.buenosaireslibre.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: org-jira.el

[Bao Haojun]

OSiUX <xuiso@osiux.com.ar> writes:

> El lun, 02 ene 2012, Bao Haojun decía:
>
>> Hi, all
>> 
>> I have implemented org-jira.el, bringing org-mode and Jira system
>> together.
>> 
>> Wrote a Wiki page for it on emacswiki:
>> http://www.emacswiki.org/emacs/OrgJiraMode
>> 
>> Hope somebody find it useful, if he/she is also using Jira and loves
>> org-mode.
>> 
>> 
>> 
>
> after running Mx jira2-login, I get the following error:
>
>     Symbol's function definition is void: auth-source-search
>
> howto configure login?
Sorry, must be because I'm using emacs24. I will look into it and get back.

Re: org-jira.el

[Bao Haojun]

Hi, OSiUX

OSiUX <xuiso@osiux.com.ar> writes:

> El lun, 02 ene 2012, Bao Haojun decía:
>
>> Hi, all
>> 
>> I have implemented org-jira.el, bringing org-mode and Jira system
>> together.
>> 
>> Wrote a Wiki page for it on emacswiki:
>> http://www.emacswiki.org/emacs/OrgJiraMode
>> 
>> Hope somebody find it useful, if he/she is also using Jira and loves
>> org-mode.
>> 
>> 
>> 
>
> after running Mx jira2-login, I get the following error:
>
>     Symbol's function definition is void: auth-source-search
>
> howto configure login?

I have fixed it. The auth-source-search is a new API from emacs24.

With the new code, you will be prompted for username and password if you
are using a lower version of EMACS.

BTW, I have also renamed jira2 to jiralib, so after you check out the
new code, you need change your .emacs accordingly:

#+begin_src emacs-lisp
(setq jiralib-url "http://jira-host")
(require 'org-jira) ;jiralib is not explicitly required, since org-jira will load it
#+end_src

Thanks.

-- 
All the best

 Bao Haojun

Re: org-jira.el

[OSiUX]

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

El vie, 06 ene 2012, Bao Haojun decía:

> Hi, OSiUX
> 
> OSiUX <xuiso@osiux.com.ar> writes:
> 
> > El lun, 02 ene 2012, Bao Haojun decía:
> >
> >> Hi, all
> >> 
> >> I have implemented org-jira.el, bringing org-mode and Jira system
> >> together.
> >> 
> >> Wrote a Wiki page for it on emacswiki:
> >> http://www.emacswiki.org/emacs/OrgJiraMode
> >> 
> >> Hope somebody find it useful, if he/she is also using Jira and loves
> >> org-mode.
> >> 
> >> 
> >> 
> >
> > after running Mx jira2-login, I get the following error:
> >
> >     Symbol's function definition is void: auth-source-search
> >
> > howto configure login?
> 
> I have fixed it. The auth-source-search is a new API from emacs24.
> 
> With the new code, you will be prompted for username and password if you
> are using a lower version of EMACS.
> 
> BTW, I have also renamed jira2 to jiralib, so after you check out the
> new code, you need change your .emacs accordingly:
> 
> #+begin_src emacs-lisp
> (setq jiralib-url "http://jira-host")
> (require 'org-jira) ;jiralib is not explicitly required, since org-jira will load it
> #+end_src
> 
> Thanks.
> 
> -- 
> All the best
> 
>  Bao Haojun

Hi Bao Haojun,

I finally discovered the error, I was using an anonymous proxy server
and JIRA apparently did not return the correct xml.

Does not work in emacs, but in emacs 24 enabling the debug managed to
capture the error::

  (let ( (url-request-method "GET") (url-package-name                )) 
  (let ( ("soap-client.el") (url-package-version "1.0")              )) 
  (let ( ((url-mime-charset-string "utf-8;q=1, iso-8859-1;q=0.5")    )) 
  (let ( ((url-request-coding-system (quote utf-8))                  )) 
  (let ( ((url-http-attempt-keepalives nil)) (let ( (buffer          )) 
  (let ( ((url-retrieve-synchronously url))) (with-current-buffer    )) 
  (let ( (buffer (declare (special url-http-response-status))        )) 
  (let ( ((if (> url-http-response-status 299) (error "Error         )) 
  (let ( (retrieving WSDL: %s" url-http-response-status mime-part    )) 
  (let ( ((mm-dissect-buffer t t))) (unless mime-part (error "Failed )) 
  (let ( (to decode response from server")) (unless (equal (car      )) 
  (let ( ((mm-handle-type mime-part)) "text/xml") (error "Server     )) 
  (let ( (response is not an XML document"                           )) 

... then disable the proxy, start using emacs and execute
org-jira-get-projects got the list of projects and then some issues.

Excellent work, I hope that the error messages to help correct for
emacs23 org-jira.

Finally I would like to know where to change the path for the projects,
actually: /home/.org-jira

Thank you very much!
I'll stop now copy and paste from jira to  org-mode. ;-)


Enviroment Emacs23:

- Org-mode commit: 258aad0b9a428cec9195b22063e42df77dee19c2
- GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.6) of
  2011-10-25 on trouble, modified by Debian
- org-jira commit: 6fd1fd891eb716871dc5d6d680f99585f1f3602e

Enviroment Emacs24
- Org-mode commit: 56c73255c0bdd27ac42af0a02ecea9336c4594d6
- GNU Emacs 24.0.92.1 (x86_64-pc-linux-gnu, GTK+ Version 3.2.3) of
  2012-01-05 on zelenka, modified by Debian
- org-jira commit: 6fd1fd891eb716871dc5d6d680f99585f1f3602e

-- 

::

  Osiris Alejandro Gomez (OSiUX) osiux@osiux.com.ar
  AA70 93FD B6EF EB42 6920 7530 A799 B226 74C8 A3FE
  http://osiux.com http://wiki.buenosaireslibre.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: org-jira.el

[Bao Haojun]

Hi OSiUX,



OSiUX <xuiso@osiux.com.ar> writes:
> Hi Bao Haojun,
>
> I finally discovered the error, I was using an anonymous proxy server
> and JIRA apparently did not return the correct xml.
>
> Does not work in emacs, but in emacs 24 enabling the debug managed to
> capture the error::
>
>   (let ( (url-request-method "GET") (url-package-name                )) 
>   (let ( ("soap-client.el") (url-package-version "1.0")              )) 
>   (let ( ((url-mime-charset-string "utf-8;q=1, iso-8859-1;q=0.5")    )) 
>   (let ( ((url-request-coding-system (quote utf-8))                  )) 
>   (let ( ((url-http-attempt-keepalives nil)) (let ( (buffer          )) 
>   (let ( ((url-retrieve-synchronously url))) (with-current-buffer    )) 
>   (let ( (buffer (declare (special url-http-response-status))        )) 
>   (let ( ((if (> url-http-response-status 299) (error "Error         )) 
>   (let ( (retrieving WSDL: %s" url-http-response-status mime-part    )) 
>   (let ( ((mm-dissect-buffer t t))) (unless mime-part (error "Failed )) 
>   (let ( (to decode response from server")) (unless (equal (car      )) 
>   (let ( ((mm-handle-type mime-part)) "text/xml") (error "Server     )) 
>   (let ( (response is not an XML document"                           )) 
>
> ... then disable the proxy, start using emacs and execute
> org-jira-get-projects got the list of projects and then some issues.
>
> Excellent work, I hope that the error messages to help correct for
> emacs23 org-jira.
>
> Finally I would like to know where to change the path for the projects,
> actually: /home/.org-jira
>
> Thank you very much!
> I'll stop now copy and paste from jira to  org-mode. ;-)
>
>
> Enviroment Emacs23:
>
> - Org-mode commit: 258aad0b9a428cec9195b22063e42df77dee19c2
> - GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.6) of
>   2011-10-25 on trouble, modified by Debian
> - org-jira commit: 6fd1fd891eb716871dc5d6d680f99585f1f3602e
>
> Enviroment Emacs24
> - Org-mode commit: 56c73255c0bdd27ac42af0a02ecea9336c4594d6
> - GNU Emacs 24.0.92.1 (x86_64-pc-linux-gnu, GTK+ Version 3.2.3) of
>   2012-01-05 on zelenka, modified by Debian
> - org-jira commit: 6fd1fd891eb716871dc5d6d680f99585f1f3602e

Great!

I was also using proxy through setting the url-proxy-services variable,
and the org-jira.el does not work. After some googling around, I found
that url-proxy-services supports disabling proxy for some hosts:

(setq url-proxy-services 
      (quote
       (("http" . "localhost:8580")
        ("no_proxy" . "^[^.]*$\\|sina.com"))))

(just in case you don't know this already:-)

For the org-jira save path, I will make it a defcustom.

Thanks!
-- 
All the best

 Bao Haojun