List of test cases in Confluence Pages
I need to publish a list of the created test cases in a Confluence Page. I followed the instructions here (https://support.smartbear.com/zephyr-scale-server/docs/reports/live-reports-in-confluence.html) but couldn't find the report I'm looking for. I just want to have a table with the created test cases in Jira (no executions results, no summarised amount por Epic, component, folder, etc), just the list of the test cases created in Jira. Similar to the "Test Cases (summary) " report available as Jira Report but in Confluence pages. Is that possible? If not, is it possible to run a query to retrieve test cases like similar to JQL or any other work around? I just want to have in Confluence, a table with the test cases Summaries and some other fields, having each of them links to the specific test in Jira. Thank you! Carolina.
Don't reveal SwaggerHub APIKey in requests from SwaggerHub Integration for Confluence
Could you please consider proxying any authenticated calls from the Confluence page to the SwaggerHub API back through the domain that you presumably serve the widget content from (https://confluence-plugin.swaggerhub.com)? I'm not sure what constraints exist with the Confluence plugin model, but hopefully this would allow you to manage all sensitive state (ApiKey storage) externally in a location we already trust, and form the appropriate authenticated requests to the SwaggerHub API from there. As things stand right now, the SwaggerHub API requests are observable using browser dev tools as the Confluence page renders. These requests include the chosen SwaggerHub ApiKey in the authorization header. This is a security concern for us as we have external parties and partners who we grant visibility to areas of our Confluence tenant so they can view documentation which includes api specifications. Once the ApiKey is compromised, the holder has far more than the readonly-access to specific API specifications that we intended. There are probably other ways to address this, but the proxy approach seemed the most pragmatic to me. We've worked around this issue in the past with other Confluence swagger plugins by only using exported specifications that are attached to the page. However, you are in a good position to allow the convenient referencing of the api specifications in their natural home in SwaggerHub, while keeping the communication paths secure.Allow resolution/selection of API version in SwaggerHub Integration for Confluence
Would be useful to allow just the base url to a SwaggerHub API to be specified in the widget configuration. For example: https://api.swaggerhub.com/apis/acme/products Rather than:https://api.swaggerhub.com/apis/acme/products/1.1.0 When the Confluence page is later browsed (and assuming the url is to SwaggerHub), then the default API version should be automatically resolved. This would allow the current state of the API to be reflected in Confluence without requiring new edits every time a new version is published in SwaggerHub. An extension to this would be to allow the users to choose from the different published versions when browsing the page. This should be an opt-in feature on the widget configuration.