Hey,
the official AUI 8 upgrade guide will be released closer to the Jira 8.0 release. In the meantime, have a look at this doc - it contains the most important changes + some best practices we’ve created while upgrading AUI in Jira, and links to AUI 8 change log. The change log is being updated on a regular basis and will be turned into the upgrade guide.
eap7 comments ( dev mode):
Wrong board rendering on FF & Chrome
Error 500 on Issue Search after selecting a project in basic mode
Thanks for your comments!
ad.1. We are aware of this issue. We will be working hard to fix it and some other visual glitches too as soon as possible.
ad.2. I couldn’t reproduce that. I’ve asked teammate to investigate it but in the meantime I’d be glad if you could share more details: steps to reproduce and the environment.
Hi, as @mrzymski said, we’d need some more details to investigate. Jira should log an exception that lead to this 500. Would you mind sharing that?
Hi, ad2.
environment:
Linux 4.15.0-38-generic #41~16.04.1-Ubuntu SMP Wed Oct 10 20:16:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Java™ SE Runtime Environment (build 1.8.0_191-b12)
package: atlassian-jira-software-8.0.0-EAP07.tar.gz
Log in js file 
eap7 issue search error.txt.js (84.9 KB)
@karol.jedryka Thanks for reporting and providing the log! This looks like a problem with DevStatus plugin. This is a known bug that will be fixed in the next EAP.
Hey @danielwester,
I’ve got a test preview of the AUI 8 docs + upgrade guide on a netlify branch build.
Our team needs to update AUI’s build process to allow us to pre-publish docs ahead of the release. That’s on me. The team has an epic for docs improvements, so I’ve added AUI-4944 to the list.
Hi,
Package: atlassian-jira-software-8.0.0-EAP08.zip
On scrum board and backlog:
Caused by: java.lang.NoSuchMethodError: com.atlassian.ozymandias.SafePluginPointAccess.safe(Lcom/google/common/base/Function;)Lcom/google/common/base/Function;
Environment as described in my previous post
SafePluginPointAccess.safe.log.js (3.4 KB)
Hey,
tx for bringing that up.
It seems there is an issue with this EAP and this is causing the error. We’ll be publishing a new version of the EAP - 8.0.0-EAP08-fixed - in a couple of hours.
The version containing the fix is now available for download:
Hi,
Since some API changes in Jira 8 I think I will need to maintain two different version of add-on one for Jira 7 and one jira 8.
In Jira 8.
doc.add(new StringField(this.getDocumentFieldId(), (String) value, Field.Store.YES));
In Jira 7
doc.add(new Field(this.getDocumentFieldId(), (String) value, Field.Store.YES, Field.Index.NOT_ANALYZED_NO_NORMS));
What are you strategies for situations like these? Do you have recommendation for my specific case?
Thanks.
The problem is in the import declaration. If a package is no longer available, you will run into serious problems when Java tries to load the file.
So, use full names for those classes and some sort of control based in the Jira version.
Example:
x.X has been replaced by y.Y in Jira 8.
===========
import x;
…
new X();
…
==============
===============
//no import: nor x nor y.
…
if(<Jira version <8 >)
new x.X();
else
new y.Y()
…
Java reflection can also help.
We use both approaches.
It seems like this will be the perfect time to bring the polyfill used for Array.prototype.find and Array.prototype.findIndex into alignment with the industry standard outlined by MDN.
For more info see: [JRASERVER-66096] Can't override Array.prototype.find() - Create and track feature requests for Atlassian products.
@denizoguz Like Pablo suggested, reflection can help BUT it’s a question of technical debt. You can either use reflection (good approach for where there is minimal impact) or fork the code and have multiple jars (good approach for where the code changes are huge). Reflection will may also have a performance impact.
Basically you have to pick between two evils. My personal approach is to fork the code if it’s not a huge difference since after 2 years I can retire things much easier and not have extra baggage. But that’s just me. Pretty certain others will have other opinions.
Thanks everyone for sharing their thoughts. In the past, I have used two different releases. I have noticed some downside of this approach. First, users using previous version of Jira may not notice you have a compatible version if they don’t click on “more versions” link on the marketplace. Second, on the UPM they always see a warning that there is a more recent incompatible version (the add-on version for new Jira) exist in the marketplace. I think, this time I will try to go with single release as much as I can. I will create a Jira compatibility class for collecting my reflection utilities, like this:
package com.deniz.jira.reminders;
import com.atlassian.jira.bc.issue.search.SearchService;
import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.search.*;
import com.atlassian.jira.web.bean.PagerFilter;
import com.atlassian.query.Query;
import com.atlassian.sal.api.ApplicationProperties;
import org.slf4j.*;
import javax.annotation.Nonnull;
import java.lang.reflect.*;
import java.util.List;
import java.util.regex.*;
public class JiraVersionCompatibilitySupport {
private static final Logger log = LoggerFactory.getLogger(JiraVersionCompatibilitySupport.class);
private final SearchService searchService;
private Integer majorVersion;
private Integer minorVersion;
private Method getResults;
private Method getIssues;
public JiraVersionCompatibilitySupport(ApplicationProperties applicationProperties, SearchService searchService) {
this.searchService = searchService;
decodeJIRAVersion(applicationProperties);
initMethods();
}
private void decodeJIRAVersion(ApplicationProperties salAppProperties) {
String versionString = salAppProperties.getVersion();
try {
String versionRegex = "^(\\d+)\\.(\\d+)";
Pattern versionPattern = Pattern.compile(versionRegex);
Matcher versionMatcher = versionPattern.matcher(versionString);
//noinspection ResultOfMethodCallIgnored
versionMatcher.find();
majorVersion = Integer.decode(versionMatcher.group(1));
minorVersion = Integer.decode(versionMatcher.group(2));
} catch (Exception e) {
log.error("Can't decode major and minor version number from:" + versionString);
}
}
private void initMethods() {
try {
if (majorVersion > 7) {
this.getResults = SearchResults.class.getMethod("getResults");
} else {
this.getIssues = SearchResults.class.getMethod("getIssues");
}
} catch (NoSuchMethodException e) {
log.error("Can't get method references using reflection", e);
throw new RuntimeException(e); //fail installation of addon
}
}
@Nonnull
public List<Issue> search(Query jqlQuery, PagerFilter pagerFilter) throws SearchException {
SearchResults searchResults = searchService.search(null, jqlQuery, pagerFilter);
return getIssuesFromSearchResult(searchResults);
}
private List<Issue> getIssuesFromSearchResult(SearchResults searchResults) {
try {
if (majorVersion > 7) {
return (List<Issue>) getResults.invoke(searchResults);
} else {
return (List<Issue>) getIssues.invoke(searchResults);
}
} catch (IllegalAccessException | InvocationTargetException e) {
log.error("Can't get issue list from SearchResults", e);
throw new RuntimeException(e);
}
}
}
Is web resource key of Dialog2 changed for AUI 8?
For AUI 8 it is displayed as “com.atlassian.auiplugin:aui-dialog2” but for AUI 7 it was “com.atlassian.auiplugin:dialog2”.
The web-resource keys in AUI 8 were normalised to follow a standard pattern of :aui-<singular noun of the component>. However, the previous web-resource keys for each component will continue to work throughout AUI 8. As such, requiring the :dialog2 web-resource will still work in AUI 8 (and therefore Jira 8).
Hi there,
With the latest Service Desk EAPs we’ve been experiencing H2’s JdbsSQLExceptions being thrown upon creating Request Types, like the one below.
com.querydsl.core.QueryException: Caught JdbcSQLException for select count(*) from dual where "AO_54307E_VIEWPORTFORM"."VIEWPORT_ID" = ? and "AO_54307E_VIEWPORTFORM"."KEY" = ?
at com.querydsl.sql.DefaultSQLExceptionTranslator.translate(DefaultSQLExceptionTranslator.java:50)
at com.querydsl.sql.Configuration.translate(Configuration.java:459)
at com.querydsl.sql.AbstractSQLQuery.unsafeCount(AbstractSQLQuery.java:627)
at com.querydsl.sql.AbstractSQLQuery.fetchCount(AbstractSQLQuery.java:132)
at com.atlassian.servicedesk.internal.feature.customer.request.requesttype.RequestTypeQStoreImpl.lambda$requestTypeKeyExists$12(RequestTypeQStoreImpl.java:328)
at com.atlassian.pocketknife.internal.querydsl.DatabaseAccessorImpl.lambda$execute$0(DatabaseAccessorImpl.java:69)
at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.executeInternal(DefaultTransactionalExecutor.java:87)
...
at io.atlassian.fugue.Either.flatMap(Either.java:231)
at com.atlassian.pocketknife.step.EitherStep3.then(EitherStep3.java:24)
at com.atlassian.servicedesk.internal.feature.customer.request.requesttype.RequestTypeServiceOldImpl.createRequestType(RequestTypeServiceOldImpl.java:386)
at com.atlassian.servicedesk.internal.feature.customer.request.requesttype.RequestTypeServiceImpl.createRequestType(RequestTypeServiceImpl.java:55)
...
Here’s the calling code:
RequestTypeService requestTypeService = ComponentAccessor.getOSGiComponentInstanceOfType(RequestTypeService.class);
RequestTypeCreateParameters.Builder cb = requestTypeService.newCreateBuilder();
RequestTypeCreateParameters createParameters = cb
.serviceDesk(serviceDesk)
.issueType(issueType)
.description("")
.helpText("")
.name("ExampleName")
.build();
RequestType requestType = requestTypeService.createRequestType(user, createParameters);
It was working fine in EAP05 (m0010) and before.
Please let me know if there is a better place to report such stuff.
Thanks,
Vasiliy
Hi @mmichalak,
we discovered a bug in Jira 8 EAP that still isn’t fixed in the Beta.
In the select2.css file (or rather com.atlassian.auiplugin:split_aui.component.form.select2.css as it is called when downloaded), a change was made from previous versions that doesn’t make any sense:
@media all,(-webkit-min-device-pixel-ratio: 1.5),(min--moz-device-pixel-ratio:1.5) {
.aui-select2-container.select2-container .select2-search-choice-close,.aui-select2-container.select2-container .select2-choice abbr {
background:url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAAICAQAAABuBnYAAAAAKUlEQVQI12NgYFj0nwEKwKxF/9P+Q4TgLAgDIQEVQuJiCKBpwWoosrUAzbg31XT4p6QAAAAASUVORK5CYII=') 0 0 no-repeat !important;
background-size: 8px !important
}
}
became
@media ,(-webkit-min-device-pixel-ratio: 1.5),(min-resolution:1.5dppx) {
.aui-select2-container.select2-container .select2-choice abbr,.aui-select2-container.select2-container .select2-search-choice-close {
background:url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAAICAQAAABuBnYAAAAAKUlEQVQI12NgYFj0nwEKwKxF/9P+Q4TgLAgDIQEVQuJiCKBpwWoosrUAzbg31XT4p6QAAAAASUVORK5CYII=") 0 0 no-repeat!important;
background-size: 8px!important
}
}
Notice the missing “all” before the comma? It looks like someone inadvertently deleted it (if it were intentional, the comme would be gone, too).
The impact is that the “x” to delete selected items in a Select2 component is distorted on low-resolution screens (non-Retina or equivalent). For example:
becomes:
I know it doesn’t sound too bad, but it’s ugly and sooooo easy to fix…
To reproduce the issue, create a Select2 component with the allowClear option set to true, and display it on a low-res screen, or if on a Retina display, lower the zoom to 67% (and get a magnifying glass 
)
I hope it can be fixed before the release,
Cheers,
David
Cheers for the feedback @david2! Some other people noticed this, too, so we’ve fixed it in v8.0.2 of AUI. The issue key: [AUI-4795] - Ecosystem Jira.