Jira

Changelog

1. 0.10.0

   Jira 0.10.0: the site to work in is a Jira connection

   Jira used to be configured on the plugin's own page: a url, an email and a token. That meant one Jira per workspace, and its token typed into a plugin setting rather than kept where a workspace keeps hosts.

   The plugin now brings a connection kind of its own, Jira. Add one with the site's root as the URL and point the plugin's jira parameter at it. Cloud authenticates with Basic and email:token as the secret; Server and Data Center with a Bearer personal access token. Which of the two it is used to be read off whether an email was set, and is now read off the connection's auth kind - so search still takes the right endpoint for each, and people are still named by accountId on Cloud and by name on Server. The project setting stays where it was.

   Coming from 0.9: the url, email and token parameters are gone. Make a Jira connection from them and point jira at it. This needs a server that hands a plugin's own kind of connection over with its address; on an older one the plugin says so rather than calling nowhere.

2. 0.9.0

   Jira 0.9.0: did everyone log their hours last week

   "Go through the team and check who logged all their hours on tickets last week" is a question Jira can answer and the plugin could not ask: nothing in it read the work log, and nothing listed a team.

   timeLogged(user, from, to) answers what one person logged, day by day. Both dates empty means last week, Monday to Sunday, because that is what the question means when it is asked on a Monday. Every calendar day in the range is answered, weekends included, each with its weekday, its hours - 0 where nothing was logged - and the entries behind them. So a gap is a weekday with fewer hours than the team expects rather than a date missing from a list, and a Saturday with 0 is not a gap at all. The check itself stays the workflow's: it knows whether the team logs eight hours or seven and a half.

   It is two steps inside, because that is how Jira keeps it: JQL finds the issues somebody logged on in the range, then each issue's work log is read and only their entries in the range are kept - other people log on the same issues, and the JQL match is by issue, not by entry. The date is read off the entry's started, which Jira spells with the logger's own offset, so a day is the day it was for the person logging it. Cloud pages the search by a token and Server by an offset; both are walked.

   The user is said the way updateIssue takes one - "me", a display name, a username, an email or an id - and groupMembers(group) lists a Jira group by name, answering each member's id, which is what the loop passes, beside the display name the report says.

   Where Tempo is in use its entries are mirrored into Jira's work log and appear here; its approval state does not, and lives in Tempo's own API.

3. 0.7.0

   Jira 0.7.0: set a field on an issue that already exists, and say who

   0.6.0 taught createIssue the fields a project insists on, and the first ticket raised with it was missing its team - not refused, just empty, because the field is optional. The agent agreed it was empty, asked which team, was told, and then had nowhere to put the answer: the plugin could raise an issue with a field and could not set that field afterwards. "You forgot the team" was a new ticket or nothing.

   updateIssue(key, fields) takes the same map createIssue does - names for keys, labels for values - and sets those fields on the issue. It resolves them against the issue's own edit metadata rather than the project's create form, because what can be changed depends on the issue, its status and the token; the names a refusal offers are then the ones that would actually work, and a label that is not a choice is refused with the choices, so one wrong guess costs one call. Jira keeps that metadata as a map keyed by field id where the create form is a list, and the entry builder now serves both.

   The next thing asked was "assign it to yourself", and that failed for a different reason: a user field took an account id, and an agent does not know its own. So a user is now said the way people say one. "me" is whoever the token is, asked of Jira. A display name, a username or an email is looked up the way the site's own picker does it - Cloud searches by query, Server by username - and several matches are refused with their names rather than guessed between, unless one of them is exactly what was said. An id still goes through as one, for a caller who has it.

   Moving between statuses stays transition and saying something stays comment; this is for the fields between.

4. 0.6.0

   Jira 0.6.0: the fields a project insists on

   A project can make fields of its own mandatory on a new issue - "Occurs on: PROD, UAT or DEV", "Kind of work: one of six" - and Jira refuses a create that leaves one out. createIssue took a project, a type, a summary and a description and nothing else, so in such a project it could not raise anything at all: an agent asked to file a bug would learn the two fields from the refusal, ask the person for the values, and then have nowhere to put them.

   On the wire those fields are customfield_10123, with a shape per kind: a choice is { id }, a user is { accountId } on Cloud and { name } on Server, a list is a list of those. Nobody calling from a workflow, and no model calling from an agent, should have to know any of that.

   So form(project, type) reads the create metadata and answers the whole form: every field by name, which are required, and the labels a choice takes. And createIssue grows a fields map, keyed by those names and valued by those labels, which it resolves against the same metadata and turns into Jira's shape itself - "Occurs on": "DEV" leaves as customfield_10123: { id: "10203" }. A list takes a list or one string with commas in it; a number is checked to be one; a label that is not one of the choices is refused here, with the choices, rather than by Jira with an id. A field id works as a key too, and an object goes through untouched, so a caller who knows Jira's shape for something this does not cover can still say it. A create with nothing extra stays one request.

   Cloud and Data Center spell the metadata pages differently - issueTypes and fields against values for both - and both spellings are read.

   One more thing the refusal fixed: a Jira error used to be reported by its first field only, so a project insisting on two fields cost two round trips to learn about. Every field it names is in the sentence now.

5. 0.5.1

   Every plugin takes a patch version

   Thirteen patches, because what changed is a manifest field: category became tags in the last commit and no code moved with it. Patch is the honest size of that.

   Worth knowing what a version bump does here, since the last two releases deliberately avoided one. The schema says publishing a key again with a new version replaces the file and moves the listing back to the top of "newest first" - so this puts all thirteen there at once, which makes that ordering say nothing for this batch. And a server compares the version against what it recorded at install to decide whether to offer an update, so every installation of every plugin will now say one is available, for tags.

   That is the cost of asking the catalogue to carry a number that moved. The alternative - republishing the same versions, which is what the schema means by fixing a description - was what the previous two releases did.