Platform 7 changes to alternative resource directories

Confluence Development Confluence Data Center
1

Hey,

This is one for @mkemp specifically, hello again!

A change was introduced in Bitbucket which now means that com.atlassian.plugin.util.resource.AlternativeDirectoryResourceLoader#getResourceDirectories only returns results if dev mode is enabled.

I don’t know of any production use-case for this system property, there should be none.

Well, I have one! ScriptRunner allows customers to configure custom web fragments, and in addition this means we allow configuring custom web resources.

In ScriptRunner there is a “script root” in the shared home directory. To enable loading additional CSS/JS resources, we instruct customers to configure their script root directory as an alternative resource directory.

Documentation for this feature can be found here: https://docs.adaptavist.com/sr4js/latest/features/fragments/custom-fragments/web-resource#setup

We can’t instruct customers to enable dev mode in production. I’m not sure how we can enable this functionality otherwise utilising public API?

Cheers in advance!

Reece

1 Like
2

This will be a blocker for many customers, it’s quite a common use case to use ScriptRunner to bundle in a bit of custom JS/CSS, for example to create custom scripted macros.

2 Likes
3

Agreed, we use this in SpaceX Jira and Confluence data center instances. We specifically use these as a better way to manage the extensive scripts and customizations we’ve added over the years.

2 Likes
4

Ah, interesting, thanks for the report!

We’d love to unblock y’all!

I’m currently inclined to introduce a new Java API to support this use-case because;

  • Security - we probably want avoid this feature being used to attack customers
  • Caching - WRM, CDN, and browsers will cache web-resources unless the URL changes, this currently requires a plugin system event to occur. We want customers to be able to see their changes not long after making them
  • Maintainability - we would want to force ourselves to consider this use case when we make changes to Atlassian code so we don’t accidentally break this again in the future. Maybe ScriptRunner could end up with less code on the other side of this

I’m sure you or someone else has already thought about this and got opinions on it. IDK, but I’d guess there’s already code dealing with these in ScriptRunner. So I’d like to organise a catch up to see what we can do. After that I’ll go back and talk to other Atlassians, get consensus, iterate with y’all again and get implementing. Of course we could always end up with another solution, but I think we should talk first.

Thanks for data point!

3 Likes
5

I’ve shared another data point privately with our TPM about the potential number of impacted customers.

A catch up sounds good, I’m happy to share code examples, and walk through how this works in ScriptRunner land.

Cheers @mkemp !