[Advanced Custom Fields Pro V5.8.4
Facunda Ganesh
Creating an issue using the Jira REST API is as simple as making a POST with a JSON document. To create an issue,you will need to know certain key metadata, like the ID of the project that the issue will be created in, or theID of the issue type. You can request the create metadata for all issue types across all projects by usingthe createmeta resource.
If you only want a subset of this information, specify the desired projects and issue types as query parameters.For example, this request will return the create metadata for the Bug issue type in the Jira project:
Creating an issue using the Jira REST API is as simple as making a POST with a JSON document. To create an issue, you will need to know certain key metadata, like the ID of the project that the issue will be created in, the ID of the issue type, and which fields to fill.First, you need to decide which project to use. You can get a list of all the projects from the following endpoint:
This example uses the project ID and issue type ID rather than the key and name respectively. This is usefulif you only have the IDs. For example, your integration or script may have previously requested and saved onlythe IDs of the project and issue type.
In the Jira REST API, custom fields are uniquely identified by the field ID, as the display names are not uniquewithin a Jira instance. For example, you could have two fields named "Escalation date", one with an ID of "12221"and one with an ID of "12222".
For example, the "Story points" custom field with ID = "10000" is referenced as customfield\_10000 for REST calls.You can get this reference identifier by requesting the create metadata for the issue type.
The example below uses a custom free text field named "Explanation" that has an ID of 11050. Note that wereference the field by customfield\_11050 and that the name of the field "Explanation" is not used anywhere.
The examples below show how to set the values for different types of custom fields in the input data.For Jira versions earlier than 8.4 you should retrieve custom field ID from the createmeta endpoint.For Jira versions 8.4 and later you should retrieve custom field ID from the /issue/createmeta/projectIdOrKey/issuetypes/issueTypeId endpoint.
Time tracking must be enabled to set these fields. In addition, if you use the Jira "Legacy" time tracking mode(set by a Jira Administrator), then only the remaining estimate can be set, so the originalestimate fieldshould not be included in the REST request.
Two additional URL parameters are provided in the request: startAt and maxResults. These parameters specifythe starting issue returned in the JQL results and the number of issues from that starting issue respectively.
This example request searches for issues assigned to a user with the username "charlie" and orders the returnedissues by due date. The ordering is specified by using an order by clause in the JQL query itself(not via a URL parameter in your REST API call).
This example request searches for issues assigned to a user with the username "charlie" and restricts the issuefields returned to a specified set. The fields restriction is specified by supplying an additional URL parameter fields, which lists the Jira fields returned in the JQL results.Each Jira field in the list should be comma-separated, for example, fields=id,key.
If your JQL query is too large to specify in a URL parameter, you can POST your JQL query (in JSON format) tothe Jira REST API search resource instead.Any additional URL parameters (apart from the url parameter) described above must be included in yourJSON-formatted JQL query.
To create an issue in Jira, you first need to specify a project and issue type. These together are referred toin Jira as an Issue context and are used to find the Jira schemes that control what fields are availablefor an issue, what the default values are, and what fields are mandatory.
If you prefer, by omitting the projectKeys and issuetypeNames parameters you can retrieve all the issuefield data at once for all projects and issue types. However, this approach could amount to a very large response and couldtake some time to build on systems with a large number of projects and issue types.
After selecting a project you will need an issue type. In Jira The Issue type together with the project is referred to as an Issue context and it is used to find the Jira schemes that control which fields are available for an issue, what the default values are, and which fields are mandatory.
When you have the project and the issue type, you can retrieve the information for the issue fields by calling the /issue/createmeta/projectIdOrKey/issuetypes/issueTypeId endpoint. The response will be paged.
If you are building an integration that works across Jira versions (versions later and earlier than 8.4), you may want to check if the new endpoints are already available for your Jira instance. To do so, use one of the entries available in the the response of the /rest/capabilities endpoint.
In the following example, 95% of the code is doing something other than interacting with the Jira REST API.So before you see the full example, let's highlight the actual REST usage out of context to show how simple itusually is. This example uses Python:
This performs a GET on the issue, checks for a successful response, and then parses the JSON response into aPython dictionary.The filters=\[auth\] line is how you tell restkit to perform BASIC Authentication.Later on, you'll reach into this Python dictionary to grab the data you want for your work.
This example shows you how to create a Jira app that uses the REST API. We want to look through all the commentson the issue and add a little tooltip that will pop-up when you hover over a link to a Jira issue.
The pop-up should contain a "quick view" of information about the target issue (similar to the example shown in the followingimage) so that you do not have to click the issue's link to see this information.
Fixed an error reporting bug that caused an email to be sent to theserver administrator each time that the server had a failed attemptto send a mobile push notification. This bug could cause a lot oferror emails on servers that are registered with the Mobile PushNotification Service, but are not signed up for a planthat includes access to this service, or not uploading basicmetadata required to verify eligibility forfree access to the service.
CVE-2024-21630: Zulip version 8.0 and its betas had a bug affectingan unlikely permissions configuration where some user roles hadpermission to create reusable invitation links to join theorganization, but lacked the permission to subscribe other users tostreams. A user with such a role could incorrectly create aninvitation link that subscribes new users to streams. Thisvulnerability is similar to CVE-2023-32677, but applies to multi-useinvitations, not single-user invites.
Added support for following a topic, with configurable notificationsettings for followed topics and flexible configuration options toautomatically follow topics when sending a message or otherwiseinteracting with it, or when mentioned. New Shift + N keyboardshortcut navigates to the next unread followed topic.
Added new unread count display style setting, controlling in whichstreams to display a numeric unread count or a simple dot unreadindicator. Defaults to numeric counts in normal streams, but a dotindicator in muted streams.
Major visual design improvements in the message feed, searcharea/navbar, and left sidebar. The gear menu was replaced with threenew redesigned menus: A help menu, a personal/avatar menu, and amore focused gear menu.
Added thumbnails and lightbox player support for video links andvideo files uploaded directly in Zulip. Previously, Zulip onlysupported this for videos hosted by third-party platforms thatprovide an embedded player, like YouTube and Vimeo.
The compose area was redesigned, with new formatting buttons formost message formatting features, including polls. Improved pastingURLs with text selected. Topic typeahead now indicates whether onewould be creating a new topic, and user typeahead now shows pronounsif a pronoun custom profile field is configured.
Added new API endpoint for sending a test push notification, tosupport an upcoming mobile feature. Realms now have a UUID sent tothe push notifications service to simplify migrating viaexport/import into a different server.
Installations using the Mobile Push NotificationsService now regularly upload basicmetadata about the organizations hosted bythe installation to the Mobile Push NotificationsService. Previously, basic metadata was uploaded only when uploadingusage statistics was also enabled via the SUBMIT_USAGE_STATISTICSsetting.
This release contains several expensive migrations, most notably0472_add_message_realm_id_indexes.py,0485_alter_usermessage_flags_and_add_index.py, and0486_clear_old_data_for_unused_usermessage_flags.py. Migration0486, in particular, cleans up stale that should only be presenton Zulip servers that were originally installed with Zulip 1.3.x orolder. If your server has millions of messages, plan for themigrations in this release to take 15 minutes or more to complete.
Minor: User group names starting with @, role:, user:, andvarious certain other special patterns are now forbidden. In theunlikely event that existing user groups have names matching thesepatterns, they will be automatically renamed on upgrade.
The behavior of the AUTH_LDAP_ADVANCED_REALM_ACCESS_CONTROL hassubtly changed. Previously, using this setting at all would blockLDAP authentication in organizations that are configured to use LDAPauthentication but not explicitly configured with advanced accesscontrols. This behavior was removed to simplify hosting multipleorganizations with different LDAP configuration preferences.
Fixed a bug where backups mightbe written using postgresql-client-16, which could not be straightforwardlyrestored into a Zulip instance, as the format is not backwards-compatible, andZulip does not yet support PostgreSQL 16.
795a8134c1