Thank you for reaching out. Note that partners don’t need to apply or opt in to receive the “Runs on Atlassian” badge as it will be rolled out for all eligible apps based on programmatically verified information.
Will the new installation time controls for analytics and log sharing apply to all cloud apps, or only apps that choose to participate in Runs on Atlassian?
We are actively investigating the most effective approach to manage analytics and log sharing, ensuring that we meet customer needs without compromising app developers’ ability to support their applications. It is important to note that our goal is for these controls to be applicable to Forge apps and Forge extensions within Connect on Forge apps. Currently, we do not have plans to modify vendor agreements to implement similar controls for Connect apps or Connect modules, however we will be transparent with customers that the controls do not apply to the Connect modules of a Connect on Forge app. I hope this clarifies our position.
You refer to “Connect modules of a Connect on Forge app” above, which implies that these analytics controls will be made available in the installation flow for any Forge app, not just a “Runs on Atlassian” app (because the latter cannot have Connect modules).
If so, this seems like it would be confusing for customers of a Connect-on-Forge app. For any serious app that collects metrics, the vendor will collect these metrics from both the Forge and Connect components of the app, period.
If there is an option on the installation screen to permit the collection of metrics/analytics, the customer would reasonably expect that this would apply to the entire app. The arcane technical difference between module types is the type of fine print that many customers will either not read or not understand (or which will generate support inquiries to vendors).
In the case of analytics, it also puts the vendor in the position of needing to solicit confirmation twice for the same feature (Can we collect metrics from Forge modules? Can we collect metrics from Connect modules?). But in this case, one setting will be on the installation screen and the other will be buried in the app settings. For apps with default-on metrics, this leads to a worse privacy outcome than a non-careful customer would expect, creating a potential trust issue.
If Atlassian is going to build an analytics switch, it would make the most sense to make this information visible to all components of the app, Forge and Connect. On the Connect side of a Connect-on-Forge app, this setting would need to be provided at least in the AP context, be usable as a display condition, and have some back-end API that can be used to query the status.
I also think it would be a mistake to build this control only on the installation screen. Admins will possibly want to toggle this on (or off) at a later date, and it should be modifiable from the UPM or AAC configuration screen.
I also do not suspect that the vendor agreement would need to be modified in order to provide this additional piece of information to vendors on the Connect side?
Note that we do consider egress when determining eligibility for Runs on Atlassian. If your app defines CSPs but has no egress, it will still qualify for Runs on Atlassian.
We advise bundling any static resources required for your apps (scripts, fonts, styles, etc.) along with your apps rather than fetching these from the internet. We recognise that it can be challenging to completely eliminate unsafe-inline, as some libraries may not function without it (e.g: styled). Note that all of our Custom UI templates make use of https://create-react-app.dev/ to bundle resources, but app developers are free to use any bundler they like.
We understand the necessity of a reference template and are currently developing one that we will share soon.
I’m re-iterating that we also need a solution for ‘dynamic’ egress, selected by the customer.
Our app will be able to run on Atlassian, but accepts URLs from the customer and fetches data from the customer specified locations.