Issue with Forge remotes and "Runs on Atlassian" program

[Daniel Platas]

Hello,

I'm struggling to find a proper solution to become compatible with the "Runs on Atlassian" program while keeping my app capabilities, due to what appears to be inconsistencies in the Forge manifest behaviour.

I have this Rovo agent that fetches public documentation from my company's instance to help guide users -- this doesn't involve customer data, so it should still be compliant with the RoA program baselines. To add permissions to this operation, I set up this "remote" attribute in my `manifest.yml` file, according to this documentation:

permissions:
  external:
    fetch:
      backend:
        ...
        - remote: "remote-docs"
remotes:
  - key: remote-docs
  baseUrl: "https://docs.adaptavist.com"
  operations:
    - fetch

This is looking all good; however, it doesn't work. This is a message running `forge eligibility -e development` after deploying:

ℹ The version of your app [8.0.0] that's deployed to [DEV development] is not eligible for the Runs on Atlassian program.
- App is using remote services
- App is egressing data

Is this a bug in the manifest configuration? Am I missing something?

On the other hand, I've successfully managed to make this work by using the config:

permissions:
  external:
   fetch:
     backend:
     ...
     - address: "docs.adaptavist.com"
       category: "analytics"
       inScopeEUD: false

Although I can guess this is not very orthodox, can I use this as a workaround if the previous, official way is suffering from a bug or is not expected to work at all for some reason?

Thanks in advance.

[Sunny Ape]

Howdy @Daniel Platas 

Because your Forge app is egressing data outside of Atlassian's domain, it's not strictly compliant with the eligibility requirements for Runs on Atlassian.

This is a contentious topic, and you'll find quite a few threads like this one over on the Developer's Community forum, where all matters regarding Forge and the Runs on Atlassian program are discussed, and where I suggest you add your voice :)

[Daniel Platas]

Hi @Sunny Ape, 

I know about this situation, but if you take a look at the documentation I linked, this is not what they say for this specific situation. Also, if you take a look at this other documentation link about Data Residency eligibility, you can see they specify my case in point number 3:

The app uses a remote backend but does not store in-scope End-User Data there: f your app interacts with remote backends solely for operations that do not involve storing in-scope End-User Data, it can be eligible for PINNED status. To ensure compliance, you must configure your manifest file appropriately.

If you see my earlier post, I defined this remote to comply with these two pieces of data documented in these links:

1. Defines a remote with a `fetch` operation.

2. Uses egress data referring to said "remote" in the manifest.

Despite this, it doesn't seem to be working as advertised, hence my post here.

[Sunny Ape]

I'm not using Forge's remote storage, so can't explain why you're experiencing that problem; your manifest definition for a remote backend fetch looks like it make sense, as far as I can see.

However, it seems to me that even though you've declared the remote properly, that would still only entitle the app to get Pinned Data Residency status for a particular location, not full 'Runs on Atlassian' approval.

I recommend that you raise the same question over on the Developer's Forum, as someone else may have encountered the same problem and knows why the app is failing the eligibility check

Sorry I can't be of more help on this topic.

[Daniel Platas]

I'm not using the remote declaration for storage either; I'm just fetching documentation, with no data egressing whatsoever. The Forge documentation states that location is only relevant when actually storing data. I must declare it as a remote because there's no other way, at least that I could discover. Ideally, I would declare in the external/fetch/backend declaration a simple

-address: "XXXX"
 inScopeEUD: false 

but somehow that doesn't work.

I'll try the developer form as well, thanks, didn't know about that one.