bwachter / bug-mode Goto Github PK

Fork of old bz-mode from https://bitbucket.org/henrik/bz-mode, now located at https://github.com/henrikolsson/bz-mode

License: GNU General Public License v2.0

Makefile 1.03% Emacs Lisp 98.97%

bug-mode's Introduction

bug-mode

A mode to interface with bug/issue tracking systems from within Emacs. This mode started out as bz-mode, but got renamed to bug-mode after work was done to support additional bug trackers.

Currently somewhat working bug trackers are:

Quick start

This is a quick start guide. Have a look at the full manual for more details. If you’re a developer, read this.

call make to generate autoloads
Edit your ~/.emacs or ~/.emacs.d/init.el:

(load-file "/path/to/bug-mode/bug.el")

M-x customize-group RET bug and adjust at least the the list of instances and the name of the default instance. The instance plist configuration could look like this:

(:foo (:url "https://foo.example" :type bz-rpc)
 :bar (:url "https://bar.example" :authinfo "~/.netrc" :type bz-rpc)
 :rally (:api-key "_yourapikey" :type rally))

M-x customize-group RET bug-faces if you don’t like the default faces
Store your credentials in authinfo format in ~/.authinfo, or specify a database location with the :authinfo property
For using Rally, generate API Keys if your subscription allows it, and set the :api-key property. With no API key configured username/password from authinfo are used as well.

bug-mode's People

Contributors

Stargazers

Watchers

Forkers

andremv tohojo thaodan

bug-mode's Issues

bug-mode/key bindings: how to add a comment?

In bug-mode/doc/manual.org, the key binding for "add comment" is marked as deprecated:

c - add comment (deprecated, will be removed)

How to add a comment then? Navigate to the comments and hit "e" (edit the field near point, if editable)?

Allow storing search queries locally

This task consists of two parts:

store search queries locally, connected to a bugzilla instance
allow synchronizing some or all queries with saved queries stored in the users bz profile

Add custom sorting for search results

Currently search results are displayed with fixed sorting. It would be useful to have the ability to easily change sorting criteria

rally: Allow information gathering from referenced rally objects

Some object references in a Rally bug contain a '_RefObjectName' field, which is suitable for displaying without additional API calls. It should be possible to follow those object references (and eventually, edit them)

Add 'remember' functionality for individuals bugs

In single bug mode it should be possible to add this bug to a locally stored list of bugs. Opening this list then would trigger a bugzilla search for all bugs in that list

rally: Resolve object references not containing _refObjectName

Some object references are not suitable for presentation without additional API calls (currently displayed as a text representation of a list). Those objects should be fetched and formatted. This is mainly important for fetching task lists of a user story.

rally: Allow specifying different API endpoint for searches

Currently search queries are executed using 'Artifact', as it provides an easy way to search all types of bugs. This prevents filtering by type specific properties, though. For example, to implement a search by iteration either 'Task' or 'HierarchicalRequirement' needs to be searched. This can already be implemented using direct calls to bug-rpc, but the query can't be repeated as the endpoint used is not stored in the results:

store endpoints with the search results
allow specifying endpoint in search queries

Allow editing already executed search queries

Currently it's possible to refresh a bug or list by executing the same search query again. It should be possible to edit that search query before executing it.

rally: Fetch field descriptions from Rally

https://rally1.rallydev.com/slm/doc/webservice/schema.jsp

Currently the assumption from Bugzilla side is that there's one type of bug, with always the same fields. Rally has multiple different objects, with different fields (and different field properties, a field may be writeable in one object, but read only in another)

To fix this the field cache should use an optional argument for object-type, and cache values per object, ideally on disk. Additionally some level of postprocessing of the downloaded data may be required to get it closer to the currently used format for field descriptions.

rally: Support multiple instances in one emacs

Rally decides to set some cookies for state information, which breaks things in interesting ways when trying to use multiple credentials due to the 'single instance' way rally is operated, and the cookies overriding supplied auth information.

To solve this URL should be told to not store cookies at all ("(url-cookie-untrusted-urls '(".*"))" in the bug-rpc-rally let), and bug-rpc-rally should parse headers and manage cookies for Rally per instance.