| Age | Commit message (Collapse) | Author |
|---|
|
Don't print any output by default.
|
|
|
|
We don't need to get the output of the executed mail sender program. I
added it for testing purposes.
|
|
Allow a "sendmail" program to be configured. If set, `deliver-email`
will spawn the program and write the email its standard input.
We can thus send the email by invoking the external program.
|
|
Include a selection of metadata values in the email.
I needed to pass `config` to `deliver-email` in order to be able to
build a URL to the ticket based on the `endpoint` field.
Also needed to make the field list a vector instead of a list, otherwise
'jzon' interpreted it as being a plist and serialized it to a JSON
object.
|
|
Take a recipient email address. Build an email containing the issue
details.
Change the `run` loop to only operate on a single issue for testing
purposes.
|
|
|
|
The Atlassian API documentation for Jira Cloud describes the difference
between version 2 and version 3:
> This documentation is for version 3 of the Jira Cloud platform REST
> API, which is the latest version but is in beta. Version 2 and version
> 3 of the API offer the same collection of operations. However, version
> 3 provides support for the Atlassian Document Format (ADF) in:
>
> * body in comments, including where comments are used in issue, issue
> link, and transition resources.
> * comment in worklogs.
> * description and environment fields in issues.
> * textarea type custom fields (multi-line text fields) in issues.
> Single line custom fields (textfield) accept a string and don't handle
> Atlassian Document Format content.
>
> However, these new features are under development and may change.
https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/#version
The Atlassian Document Format referenced is described in JSON. Here is
an excerpt of an issue description in the format:
"description": {
"version": 1,
"type": "doc",
"content": [
{
"type": "heading",
"attrs": {
"level": 2
},
"content": [
{
"type": "text",
"text": "Context"
}
]
},
{
"type": "paragraph",
"content": [
{
"type": "text",
That format would make it much harder to get an issue's description text
for easy inclusion in an email. Fortunately, we can switch to version 2
of the Cloud API with no loss of functionality, and get a plain text
description suitable for inclusion in an email message.
|
|
Include the fields we need to create an email notification for
newly-created issues.
|
|
|
|
|
|
Use `startAt` to get fresh pages of results.
|
|
Need to set the `startAt` field when making the request.
|
|
Move the loop outside this function. Makes more sense to have it in
`run`, which is doing the pagination etc. This function can worry about
watching a single issue.
|
|
For each page of issues, watch those issues. Watcher code needs to be
implemented.
|
|
This should make it easier to test with real values by passing in a
single config object.
|
|
We can later make a config from command line arguments.
Also don't require "https://" prefix from endpoint config. Doesn't make
sense to require that in the input when we can add it in the program.
|
|
|
|
This needs to be configurable as it will be different for each
organisation.
|
|
Instead of POSTing a string literal, define it with an alist and use
'jzon' to convert it to JSON.
|
|
Parse the Jira response into a hash that we can interact with.
Needed to do some finagling to get my "lib" submodule directory to be
searched for systems.
|
|
|
|
Set up a Common Lisp project skeleton and make a request to the
Atlassian API to get a filtered list of issues that the current user
isn't watching.
|
