bamboo

removed

bitbucketcloud

Continue to use ACLI release 11.3

The bamboo client was deprecated in ACLI release 11.2 and now is being removed from the distribution.

This was a difficult decision for us. We started supporting Bamboo in 2007 and it one of our largest clients with over 200 actions. Internally, we have used Bamboo extensively over the years. In late 2021, we started our migration to Bitbucket Pipelines. ACLI products completed migration a few months later and other Appfire apps followed. Bamboo 9.x is still in use by some Appfire products.

With the Feb 2024 discontinuance notice for Bamboo Server by Atlassian, we supported customer migration to Bamboo Data Center in ACLI release 11.0 so that Bamboo customers will still be supported by ACLI with ACLI release 11.3 for some time running against Bamboo Data Center 9.2 (LTS) - 9.5. However, Bamboo 9.5 will be the last officially supported release as we have discontinued testing for Bamboo releases and removing the bamboo client starting with ACLI release 12.0.

Over the last years, we have invested significantly in the Bitbucket Cloud client and especially the pipeline support to enable customers using Bitbucket Cloud and especially those customer with Bamboo migration efforts.     

jsm

removed

Continue to use ACLI release 11.3

The jsm client was deprecated in ACLI release 11.2 and now is being removed from the distribution. 

Jira Service Management customers can continue to use the Jira client for accessing Jira information in JSM instances just like before, but we are no longer supporting JSM specific actions. 

tempo

removed

Continue to use ACLI release 11.3

The tempo client was deprecated in ACLI release 11.1 and now is being removed from the distribution.

We were unable to provide meaningful and credible coverage of Tempo capabilities, so we have decided to discontinue the limited support we had. Our existing support in the Jira client for some Tempo custom fields will continue as normal. 

trello

removed

Continue to use ACLI release 11.3

The trello client was deprecated in ACLI release 11.1 and now is being removed from the distribution.

Low customer interest. We were unable to continue to extend our coverage of Trello capabilities, so we have decided to discontinue the support. 

segment

removed

Continue to use ACLI release 11.3

The segment client was deprecated in ACLI release 11.1 and now is being removed from the distribution.

Low customer interest. 

keen

removed

Continue to use ACLI release 11.3

The keen client was deprecated in ACLI release 11.1 and now is being removed from the distribution.

Low customer interest.

jira

Existing actions regarding user properties (updateUserProperty, deleteUserProperty) changed behavior. They switched from the legacy UI Managed User Properties to the newer REST managed user properties. Those are distinct sets. In the process operations getUserProperty and getUserPropertyList were added to the CLI.

If you need to keep the legacy behavior, you need to add --options legacy to your existing command line.

Atlassian does not provide an API to handle UI Manager User Properties, but offers APIs to managed the non-UI managed properties.

Sadly, the term user propertiesis overloaded by Atlassian to mean sometimes one and sometimes the other.

jiracloud

Commands using jql to search for issues.

creation and update of issues is asynchronous and a jql search might not instantly reflect the changes in particular after updating large text fields.

If exact JQL results are desired, the customer can specify a list of issue ids to be resolved exactly thanks to a new parameter “--reconcileIssue” that points to list of numeric issue ids (not issue keys).

Additionally, in order not to break existing scripts that do an immediate jql search after a write (create or update issue) we introduced a hidden .jira-reconciliation file that acts as a cache to track the 50 most recent entries created or updated by your scripts or commands. For those, it is guaranteed that the jql searches will return exact results.

In Cloud, the JQL index may not immediately reflect the latest state of issues: this is due to a recent change on Atlassian side. However, you can specify a list of specific IssueIds (referred to as reconcileIssueIds) that will be queried directly, bypassing the JQL index altogether and ensuring precise results for those entries. Our main challenge arises in scenarios where our customers' scripts update an Issue and then promptly query it using JQL expecting immediate retrievals.

To prevent breaking existing customer scripts due to these adjustments, we maintain a cache containing “recently updated issue IDs,” which are employed in the “reconcileIssueIds” parameter across all JQL queries—this ensures exact outcomes for those.

jiracloud

getIssueList

The total number of matches of a JQL query is now an approximation on cloud.

This is denoted by ~ symbol in the output: for instance 1 of ~19 issues in list

The reason is a change in Atlassian APIs that now are only able to give us back an approximate count of matches.

confluence and confluencecloud

get and get list actions for spaces, space properties, pages, blogs, comments, attachments and attachment versions.

Major interface changes. Default display output is now simple text output with selected columns deemed most likely to be wanted and quickly retrievable. Specify --outputFormat 1 to get previous default behavior with CSV output. Specify --outputType csv to get the default output as CSV. Specific columns and outputType can be specified easily to customize view. Script writers are encouraged to specify exact columns needed for their script to isolate the scripts from changes and to optimize performance.

Migration to Confluence REST API v2 for Cloud. Atlassian exploded existing endpoints in multiple small ones. This forces ACLI to do many more network calls to get the same amount of information as before. Therefore the list of columns outputted by default has been tailored to a set such that getXxx and getXxxList commands respond in an acceptable amount of time.

confluencecloud

getContentXxx operations

Performance impact.

Migration to Confluence REST API v2 for Cloud. ACLI now needs to separately request details for pages, blogs, attachments and custom contents. We kept backward compatible results by unifying the results from the multiple Atlassian endpoints which has a performance impact.

confluencecloud

blog related actions

It is not possible anymore to create a blogpost at a specific posting date in the past: every created blog will have a posting date of today. Hence, the date arguments --year, --month, --dayOfMonth to influence posting day are active only for Server and DC.

Date arguments made sense to distinguish between pages (no posting date) and blogs (with posting date) and hence those date argument are used to distinguish between pages and blogposts in other commands. For instance, --action addAttachment --space x --titile myTitle --year 2024 --month 2 --dayOfMonth 1 is attaching to a blog because date arguments are provided. However a new argument --type with values (blogpost, page ,attachment or comment) argument was added to make it clear to which type of content a command points to.

New Atlassian APIs for Confluence have removed the ability to create blog posts at a specific postingDate: date is always the current day.

We had to adapt to keep functionality as close as we could from past behavior.

bitbucketcloud

get and get list actions

Major interface and performance improvements. Default display output is now simple text output with selected columns deemed most likely to be wanted and quickly retrievable. Specify --outputFormat 1 to get previous default behavior with CSV output. Specific columns and outputType can be specified easily to customize view. Script writers are encouraged to specify exact columns needed for their script to isolate the scripts from changes and to optimize performance.

Easier to view data in text table format on reasonably sized terminal. New column selection capability makes easy to customize reports. Performance is much better if certain columns are avoided when they are not needed.

bitbucketcloud

getCommitList, runFromCommitList

getDeploymentList, runFromDeploymentList

getPipelineList, runFromPipelineList,

getCommit (only when using --commit @last and other filtering parameters)

getPipeline (only when using --pipeline @last and other filtering parameters)

Defaults to most recent items. Equivalent to setting the startDate parameter to -30d or @default.

Improve performance:
Commits, deployments, and pipelines are continuously being added and can easily grow to a large number of items. Unless a limit parameter is provided, the entire list might have to be evaluated to produce the desired list. Limiting by default prevents accidental long running requests. Use --startDate @all to avoid the default or specify a specific startDate based on your needs.

bitbucketcloud

getBranchList, getBranch (name search)

getPullRequest, getPullRequest (name search)

Defaults to most recent items. Equivalent to setting the startDate parameter to -365d or @default.

Similar to above.

bitbucketcloud

getPullRequestList column order

Having the author fields before the pull request field did not follow standards. Script writers are now encouraged with 12.0 to explicitly list the columns they need in the order they want in the columns parameter to best protect the script from future changes.

cli

provideFeedback

This was done through a Keen service no longer available

bitbucketcloud

getPullRequestList

The author columns were moved after the merge commit column on all output formats. Scripts can specify column order explicitly using the columns parameter to get previous behavior.

Design oversight not conforming to standards.

bitbucketcloud

getDownloadList

Date column renamed to Created

Clearer indication of what the column means. More consistent with other actions with a created column

bitbucketcloud

getBranchList

Target prefix removed from commit column headers and other column changes.

Consistency with other actions and avoid confusion.

bitbucketcloud

getUserList

User field no longer represents the deprecated Bitbucket cloud user name for older users. It is now consistently the nickname for all users.

Bitbucket deprecated the old usage for username even though it is still around for some compatibility things. It is confusing, so we settled on what Bitbucket recommends going forward.

jira

addFieldConfigurationScheme, addIssueTypeScreenScheme, addScreenScheme

11.0

createFieldConfigurationScheme, createIssueTypeScreenScheme, createScreenScheme

consistency across scheme actions

cli, csv, web

renderRequest

11.0

webRequest

bitbucketcloud

getSource

12.0

getFile

Both source and binary file data can be retrieved, so getFile is more appropriate terminology.

bitbucket

addBranch, removeBranch

10.6

createBranch, deleteBranch

consistency with bitbucketcloud client and general use verbage

jira

deleteComponent

10.4

removeComponent

consistency with addComponent

marketplace

getAppReviewList

10.x

getReviewList

simplification

confluence

getPageHistoryList, removePageVersion

10.x

getContentHistoryList, removeContentVersion

broader support with the content action

agile

id

10.x

board

board parameter can be used for board name or id

jira

values, value2

10.x

field

field parameter can be used multiple times and includes field name and value

jira

field2

10.x

field

field parameter can be used multiple times and includes field name and value

slack

autowait

10.x

now automatically done

all

host

10.x

url

Specify host as part of the url parameter for database access.

all

port

10.x

url

Specify port as part of the url parameter for database access.

jira, confluence, bitbucket

targetPassword, targetToken, targetUser

10.x

Use targetServer referencing a ACLI configuration entry to specify this information.