You’ll be notified once the feature has been enabled so you can start testing on the App ID you submitted in the participation form.
You’ll be invited to a slack channel where you will be able to talk to the team about feedback, challenges, and more.
We are looking forward to receiving your feedback so we can deliver a more powerful solution for you!
*Please note, that these features will only be accessible by those participating in the EAP. However we will also be posting relevant updates to ensure everyone is informed.
We tried the no-egress webtriggers as proposed in the docs. Adding the security.egress. allowDataEgress flag worked and removed the egress warning we earlier had with the eligibility command.
I had some trouble to send the correct response to get this example to work
It would be nice to have the body property in allowedResponses being a list of strings, so I can send more than one static message for the same HTTP status.
We’ll keep you updated if we have further feedback!
When using static responses, the body and status code must be exact matches, and in using JSON.stringify("Allowed static response") and JSON.stringify({body: "Allowed static response"}), we get '"Allowed static response"' and '{"body":"Allowed static response"}' respectively. Here, the static response is defined as '{"body": "Allowed static response"} inside the manifest, with an extra whitespace after the colon, and therefore your current implementation won’t work since static responses use string literal comparisons for bodies.
It is also possible to to define multiple static responses for the same status code because of allowedResponses being a list of status code and body pairs. An example of this would look like
Yes we understand the importance of ensuring that the capabilities needed to achieve “Runs on Atlassian” eligibility are working ahead of the customer-facing launch (with time for partners to adopt them). That is the sequence of events we are striving for.
Can we already release a version for production without the GA of the no-egress webtrigger?
I would not recommend this. As per our release policy, features in early access are not recommended for production use and are not subject to our typical deprecation timelines (we can change them at any time).
We are exploring if we can improve the developer experience of the no-egress web trigger to address the pain point of trying to map exactly the manifest string to the stringified JSON result. So, code changes may be needed between EAP and GA before you launch.
Hope this helps! Thanks for your feedback during the EAP.