Perfect workflow with Emacs, Org and Cron

Wanted to share how I've integrated a GTD workflow, Outlook calendar, time tracking and writing Jira & Confluence articles in Emacs. Hope others will find it useful too.

Thanks for sharing! I love the idea of exporting org reports with a cron into files with the day's timestamp as their name. This makes it easier to know what you did for a specific day, without having to jump in a big file 🙂

I'm in a similar "want Org, have Jira" situation, so this is right down my alley -- thanks so much for sharing! One thing I didn't find in your Dotfiles that you might find useful is [bug reference mode](https://www.gnu.org/software/emacs/manual/html_node/emacs/Bug-Reference.html). It transparently turns every mention of a ticket number into a link. Here's my setup for Jira: # Local Variables: # bug-reference-bug-regexp: "\\b\\(\\([A-Za-z][A-Za-z0-9]\\{1,3\\}-[0-9]+\\)\\)" # bug-reference-url-format: "https://example.atlassian.net/browse/%s" # End: Also, I noticed that you're copy/pasting new tickets into your Org file manually in the video. Coincidentally, I wrote a thing about automating this [just a few days ago](https://www.reddit.com/r/emacs/comments/ulaswe/blog_post_orgcapturing_live_jira_issues/). Check it out if you're interested.

Started watching, very useful to me so far :) Thanks

I saw that post! Seems like there are a non-zero amount of us emacsers forced into jira that aren't _that_ satisfied with org-jira. We must come up with something better!

Nice video, thanks! I am a little confused about why you have another orgfile for every (work)day ? Can't you just keep the one you have, deleting (or archiving) things that are done? I guess deleting would be ok if you push a commit to your git repo before the deletion.. Can you explain the reason why you implemented this workflow?

I can't really speak to org-jira, as I've never used it. It *does* have an impressive list of features, but I guess I just wasn't ready to commit to that back when I wanted to automate just one thing. I wouldn't be the least bit surprised though if (a) what I came up with is fully covered by org-jira already, and (b) I'll end up with somewhat of a clone of that package as I continue to hack at my workflow, lol.

It basically pulls tickets into org files, in various ways including custom jql. What it pulls seems kinda messy and it misses things like attachments. I still need to iron out a good workflow that reduces how much time I have to use jira though...

Thanks. Just ask if anything comes up.

Thanks. >why you have another orgfile for every (work)day ? That's a good question! For years, I did just that, had one main file called [`work.org`](https://work.org). I then switched to `2022-05-14.org` style files for these reasons: * It's easier to navigate a small file than a huge one (even with tags and outline nav) * I can go back to any day and see what I did on that day, what notes I had from customer meetings, kickoffs and the like. Of course, I could navigate `git log --patch`, but it's not as smooth. * If my cron job fails reporting the hours for a given day, the time report system is down, my conf is wrong, password outdated or whatever, I can easily go back and log those hours another day.

Thanks. That was indeed part of my rationale :-)

>We must come up with something better! I have tried `org-jira` and cannot remember *exactly* why I didn't continue using it, but part of it, I think, was that I just didn't dare to. Our Jira installation is complex, so many custom fields, worfklows, plugins, integrations and whatnot, that I just didn't trust `org-jira` to not mess it up. Or perhaps I should say, I didn't trust *myself* with the power of `org-jira` not not mess it up sooner or later. Perhaps I didn't invest enough time in it, but that was why I left IIRC, that and that it pulled down *so* many issues. I would rather want a lighter, per-issue, integration.

> thanks so much for sharing! You're welcome :-) > you might find useful is bug reference mode. That looks very neat, I'll definitely check it out. I wonder if it an exception list for the likes of `UTF-8`? ;-) > I wrote a thing about automating this Cool. I'll check it out.

When you had a single file how was it organized? Did you try using a date tree?

No I didn't. Is that something you would recommend? One challenge I see, in addition to a higher risk of merge conflicts when syncing the file between three machines, is how I would integrate that with reporting the Org report hours in our time reporting system. I'm sure there's a solution to that problem (pretty much everything is solvable with Emacs and a bit of `bash`), but my current script that uses `sed` to extract the report block and create statements usable by `curl` to report the time would have to be a fair bit smarter.

A little off topic but some of us are heathens with teams of people using GitHub issues and projects only no Jira tracking. Is there a good emacs workflow and or org mode for issue highlighting and management in GitHub?

Well, I can't really recommend a date tree since I don't know exactly what you need to do with these files (and I haven't even had a chance to watch your video yet —it's queued for the next time I do dishes, so later today), but I do think a single date tree file has some advantages over many files with dates as names: - You don't have to enter the dates yourself, nor to write code to automate entering the dates: Org already has that automation built in. - By narrowing to a subtree you can easily focus on a single day *or* month; files limit you to focusing on a day. - I find it a little easier to search for things in single file, since Org has more tools for that than for searching across a directory. - It reduces buffer clutter a bit; with one file per day I can easily see myself having the last 3 days or so open. Overall it's not a huge difference, but I do think Org support the single-file style a bit better. Of course, these advantages won't matter if something you need to do becomes much harde with a single file.

Very interesting. Work with jira from emacs is my dream.

Github is easy, I wish we were using it. Everything happens in magit. All you'd need is a metapackage to make `[[gh:<number>]]` links and you're away.

Ours isn't _that_ bespoke but it's a similar problem. `org-jira` doesn't pull things like attachments so for most tickets (one of our clients it's usually just a couple of screenshots and a title) it's pointless. I'd much rather do something like /u/fritzgrabo's blog post.

IIRC you can just use org-capture templates to get a structure similar to the below right? * 2022 ** January *** 25

Can you explain a little further? At work we do it the fun feel good Linux kernel way with staff and community devs also PRing and opening issues across forks. How do I make it handle org and repo ids? Also I work with teams that use the github projects feature for kanban or agile issue mgmt (flame away but not emacs relevant). Not all want column automation in project. Any insight to that or should I just ask in a new post?

Yes, that is exactly the date tree I was referring to. You can get it via a capture template that looks like: ("d" "Daily" entry (file+olp+datetree "Daily.org") "* TODO %?\n")

Thanks for saving me digging it out! Always full of gems :)

Have you not used magit/forge before? They make navigating compatible repositories a _treat_. It is probably worthy of another post, but I'll include a bit here. If I open up magit on a github project, I can see all the [issues](https://i.imgur.com/UX8Ar1f.png) and [prs](https://i.imgur.com/ZDQoYpp.png), with the already-linked [bug-reference-mode](https://www.gnu.org/software/emacs/manual/html_node/emacs/Bug-Reference.html) I can make `#34` link to topic 34 in any document I desire. If I want to review a PR, there's [code-review](https://github.com/wandersoncferreira/code-review). The only piece really missing is the new projects feature, and that's only because we don't use it at work and none of the open source projects I contribute to really use them either. Hope this is a good start!

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click! [Here is link number 1 - Previous text "prs"](https://i.imgur.com/ZDQoYpp.png) ---- ^Please ^PM ^[\/u\/eganwall](http://reddit.com/user/eganwall) ^with ^issues ^or ^feedback! ^| ^[Code](https://github.com/eganwall/FatFingerHelperBot) ^| ^[Delete](https://reddit.com/message/compose/?to=FatFingerHelperBot&subject=delete&message=delete%20i8kx4nq)

This is awesome! Thanks for sharing. I can't find the script you use for making the daily org files though... Where would they be?

Thanks! Regarding creating the daily Org files: The script can be found here: [https://gitlab.com/skybert/my-little-friends/-/blob/master/bash/org/daily](https://gitlab.com/skybert/my-little-friends/-/blob/master/bash/org/daily). You may also check out my updated slide deck at: [https://talks.skybert.net/r/2022-gtd/#/24](https://talks.skybert.net/r/2022-gtd/#/24)

Thanks! The 2nd link gives me a 404 error though. 😕

I'm embarrassed I only ever used it as a git UI not for GitHub but its clearly evolved since then. I'll try it again. Thanks!

Weird. It works for me. I've checked using two devices.

The GNU Hyperbole package has extensive built-in support for links to Github artifacts. No configuration or programming is necessary to use them, just install Hyperbole. Below are some examples of the link forms you can embed in any sort of editable file type. Then press M-RET (the Action Key) on any such reference to active it (display it in your web browser). Below are some examples from the original Hyperbole DEMO: Github References For software developers who use Github for publishing and version control, Github links are similar to social media links but reference specific Github web pages. Press M-RET on github@rswgnu to go to RSW's gihub home page.gh@rswgnu works too. References to project home pages look like this and can start with either gh# or github#: github#/hyperbole (uses user default setting) github#/rswgnu/hyperbole References to specific commits use the # hash symbol and short versions of the git commit hash code: gh#rswgnu/hyperbole/5ae3550 (if include user, must include project) github#hyperbole/5ae3550 (project can be given with user default) gh#5ae3550 (user and project defaults are used) An Action Key press on the first commit reference above works because user, project and commit hash code are all included. The second and third versions require the setup of default values, as explained in the commentary near the top of "hib-social.el". Similarly, the same file above explains how to link to pull requests, issues, branches and tags.

Thanks for the video. I guess here is the type of people who might be also interested in projects of mine: * [https://github.com/novoid/jira2org-story.py](https://github.com/novoid/jira2org-story.py) Extract Jira Issues and Generate Org-mode Headings * I was using this for a couple of years (not any more) when I was Product Owner (Scrum). This workflow is able to export single stories or whole epics and generate a much more detailed project in Org-mode. * [https://github.com/novoid/postprocess\_Org-mode\_iCal\_export](https://github.com/novoid/postprocess_Org-mode_iCal_export) * If you want to export your calendar from Org-mode to ical, this might be handy. * jiraenricher: In the upcoming days/weeks, I plan to publish a Python tool that parses a text file (Markdown, LaTeX, Orgdown, ...) and replaces placeholders for Jira ticket IDs with data from Jira. We're using this to generate and update reports that contain data from Jira. Follow [my GitLab account](https://gitlab.com/publicvoit) for this, use [my blog feed](https://karl-voit.at/how-to-use-public-voit/) or [Mastodon](https://graz.social/@publicvoit) account.

Looks like a great workflow you have there. I see several advantages over my own workflow, which makes use of a spreadsheet in org-mode. (+) Using the built-in time tracking, to be exact in minutes – I usually look at the clock and calculate minutes in my head, to add them to an existing amount of minutes. This has the disadvantages, that I need to calculate a little and that it is not as fast as simply clocking in the time using a shortcut. (+) Also I don't get an org-report from time tracking as neatly as you do, because I am not using built-in tools. Org-mode doesn't know, that my custom spreadsheet contains task times. (-) On the other hand, and that would be a problem for me, I would have to always think about starting the clock. I _will_ forget about that and then will have lost any idea of when I started to work on the task. In my spreadsheet I maintain a timestamp, which is "last updated", simply a timestamp, which I will update, whenever I add time for any task. OK, sometimes I forget … But usually I can remember approximately, when I last checked the time and retro-actively update it and then calculate the time I spent on the current task. (+) Another advantage I see in your video is, that you don't have the problem of having to put a rather short description into your tasks. It is the typical problem one has, when using tables for such things. I have to or rather should limit the length of a task description, as it will widen the spreadsheet a lot, when I write a long text there. With headings it is easier of course, because you can simply write something below a heading. It also seems more natural to use headings for such things in org-mode, as you can mark them as todo, done etc. (-) With the spreadsheet solution I have, I am less dependent on setting up multiple packages to work correctly with my org documents. (+) I don't even have anything set up to report times to Jira. Well, we are not doing that on the job, so I don't have to. If we had to, I might be even more inclined to adopt your workflow. (+) With the spreadsheet I have, I put a `#` in the first column, so that all the calculations are updated when I do `C-u C-u C-c C-c` (Or is it the other way around? Muscle memory.) or a line with I `TAB` through the table. The Outlook calendar thing looked neat. I guess you convert ICS -> ORG and the ORG file lands in a location, which you have added to the locations, where Emacs looks for agenda files. I think in this part you could have gone a bit more into details and shown some more of the code in your config, if not too sensitive. In general I think your workflow is superior, when it comes to getting things tracked in Jira. However, what would have been really cool, is you showing how to pull Jira tasks and having them in your org document with all their properties and then bidirectionally updating them on Jira, when you update them in the org document. I would probably have adapted that. Well, perhaps this be done using their API as well.

>Overall it's not a huge difference, but I do think Org support the single-file style a bit better. Yes, I agree. Org seems to have been designed around having one file. >Of course, these advantages won't matter if something you need to do becomes much harde with a single file. Yes, that was my conclusion too. Easier to report time, the same day or later and less Git merge conflicts when syncing between computers.