Issue Adjustments are intended to reproduce on cloud some functionality that is currently available on server – the ability to change the way issues appear dynamically.
As mentioned above, the new extension point is intended to allow Connect apps to alter Fields in a way similar to what P2 apps are able to do. Specifically, we want to be able to allow an app to change the user-facing display values of Fields and also change some of the way they behave.
Architecture
This would be a new module that would need to be declared in the applications descriptor/manifest. Each app would define the projects and issue types each adjustment can apply to:
At the point in time that an issue is going to be shown and it should be “adjusted”, Atlassian would reach out to the app and ask for a response with the given context and allows the app to respond with adjustments. Currently, the lifecycle hooks that are being considered are onInit and onChange. Here is a diagram of how the interaction would work:
Here is a rough look at the API: issue-adjustments.pdf (38.8 KB)
API & Code
Here is an example of it in action:
issueAdjustments.onInit(({ getFieldById }) => { // register init handler
const summary = getFieldById(‘summary’); // get info about the field
if(!summary.isHidden()){
summary.setDescription(‘This field is required’).setRequired(true); // adjust the issue's description
}
});
Getters
The following getters would be available:
getId: (void) => $PropertyType<Field, 'fieldId'>,
getName: (void) => $PropertyType<Field, ‘fieldName'>,
isHidden: (void) => $PropertyType<Field, 'isHidden'>,
isEditable: (void) => $PropertyType<Field, ‘isEditable'>,
isRequired: (void) => $PropertyType<Field, ‘isRequired'>,
getDefaultValue: (void) => $PropertyType<Field, 'defaultValue'>,
getDescription: (void) => $PropertyType<Field, 'description'>,
Setters
The following setters would be available:
setName: (value: $PropertyType<Field, 'fieldName'>) => FieldAPI,
setHidden: (value: $PropertyType<Field, 'isHidden'>) => FieldAPI,
setEditable: (value: $PropertyType<Field, 'isEditable'>) => FieldAPI,
setRequired: (value: $PropertyType<Field, 'isRequired'>) => FieldAPI,
setDefaultValue: (value: $PropertyType<Field, 'defaultValue'>) => FieldAPI,
setDescription: (value: $PropertyType<Field, 'description'>) => FieldAPI,
Timeline
The following guidelines are very rough:
Alpha release FY22 Q2, ~ Nov. 2021
Public release FY22 Q3, ~ Jan. 2022
Forge and Fields+ FY22 Q3
We plan to have an Early Access Program once we’re ready to bring on Alpha testers!
Key notes
- In the first public version will support new create issue view (Connect-only).
- Forge support is next and further improvements will be Forge-only. Future improvements could include: pages Issue view, transition screen, and JSM will be probably only in Forge.
- Issue adjustments work only on UI level no support for Rest API
- We assume that users will intentionally agree to wait for issue adjustments execution in order to get value from Issue adjustments
Constraints
- Extension points: We will support only new Global Issue Create , which is currently rolling out.
- Issue adjustment execution: UI by default will be updated only after whole lifecycle hook callback execute properly. This will reduce “jumping” UI, and add more predictability to execution.
- Performance: Issue adjustment will have time constraint on execution per lifecycle hook (
onInitandonChangemight have different limits) - Update UI will be triggered only after successful lifecycle hook execution
Performance
Since Issue Adjustments will bring extra time during mounting view - especially the initial load, we have to be super aware of performance of our solution. Also - we are on critical path when adding interactions on initialisation of Create Issue View or Issue View.