RFC-86 Bitbucket Connect to Forge: Input on the Migration Process

Hi everyone, massive apologies from myself - unfortunately I had some pretty serious stuff happen in my personal life just as I landed from TEAM25, so had to disappear for a few weeks.


@UlrichKuhnhardtIzym1:

  • Proxy module + ROA:
    • Given that it’s a condition for RoA that the App doesn’t use any “Remotes”, all the App logic would need to be running inside Forge functions.
    • If the app logic is running inside a Forge function, the function can simply call the BBC API directly and hydrate whatever extra data it needs.
    • Additionally, Forge already supports the “asUser” auth mechanism to only allow API calls to access resources available to the user making the request.
  • User Profile UI Module
    • Because users exists outside the context of a specific workspace, Forge apps cannot actually operate purely in the context of a user (due to apps being installed in the context of a workspace).
    • Instead, we’ll introduce a WorkspaceSettingsAction UI module that apps can use to render a stand-alone user-specific settings modal based on the user context provided by Forge.
    • This avoids the complexity of a user-profile-specific module outside workspace context and aligns with Jira/Confluence patterns (e.g., a “My-App Settings” page in the “More” dropdown).
    • This would be in addition to a global WorkspacePage UI module that would be triggerable from the “More” dropdown in the top nav.
  • Project settings UI module.
    • Project settings is a high priority add and will be done as part of this process.
    • In addition to that , we will review all the main Project-level screens to see if there’s any other high-value locations to add UI modules.

@JanNylund:

  • The FileViewer UI Module will be added as part of this process.

@YuriKarnilaev:

  • Profile tab UI panel
    • Please see previous response.
  • Proxy Module (Can web-triggers/remotes solve this?).
    • Please see previous response.
  • Business events: repo:transfer, pullrequest:superseded, pullrequest:approved, pullrequest:unapproved
    • repo:transfer We will look at enhancing the existing repo created/deleted events to include an indication that the event occurred in response to a transfer request. There are privacy considerations that have to be factored in here due to the workspace boundaries.
    • Review Status: Current event “review status updated” doesn’t include the new status.
      • We will update this to include this information, in addition to the reviewers.
    • pullrequest:superseded is not currently available for Connect apps in Bitbucket Cloud.
      • What use-case is this needed for that would not be covered by the pullrequest:updated event?

@christian.ott:

  • Profile tab UI panel
    • Please see previous response.
  • Code Insights Annotation UI module
    • This is something we’re considering for future enhancements, but not a “must” for this program.

@joshp:

  • File viewer module: We are planning to add this as part of this program.
  • File editor module: This is not currently implemented by any publicly available Connect app, so is not considered a dependency. It is highly likely that this will be ported to Forge in the future though.
  • Global page, similar to Jira, Confluence, Compass: This will be implemented as part of this program, triggering from the global “More” dropdown in the top nav.

Response to general RFC:

  • What happens if a user installs a Forge app via a Connect app notification.
    • The simple answer is that we would NOT provide any kind of automated uninstallation flow, and this would need to be managed by users/vendors.
    • The reason for this is simply that it’s extremely risky to have some kind of automated process, especially in regards to data retention etc, and would actually make MORE work for vendors.
    • It would effectively force all vendors to build some kind of “single-shot” automated migration process. Our view is that a manual uninstallation flow gives users and vendors the most flexibility, and so is preferred.
    • Vendors will need to manage de-duplication using event installation contexts or UI conditions if they do not want users to temporarily see duplicate apps in the UI.
  • How would the vendor link the new Forge equivalent app in the Atlassian MP as the Same listing as the current one.
    • TBD - we need to look into this further, but we wanted to validate the idea before going into it too far.
    • We have already started the conversation with Marketplace to understand how this would work.
    • Given all BBC apps are unpaid, this is probably less complicated than it would be if there was payment involved.
  • What would the install flow look like from the Marketplace/Bitbucket marketplace?
    • All installations would be centralised via the Atlassian Marketplace.
  • What would be the expectations around Paid-via-Vendor connect apps to Forge.
    • Given Forge supports PvV, we would expect it to operate the same as any other product.
    • Are there specific issues/scenarios you are concerned about?
  • Would we support linking multiple Connect apps to a single Forge app as an upgrade path?
    • In Bitbucket, yes - you would be able to point multiple Connect apps to a single Forge app as a “replacement”.
    • But not when it comes to actual app listings in the Marketplace. Vendors would have to pick a specific Marketplace listing that they want to “transfer” to an equivalent Forge app.
    • Ideally keeping all the reviews and history, etc that was originally there. But we would not support merging multiple Connect listings into one.
    • NOTE: Anything related to marketplace listings is still TBD.

Summary:

UI Modules - Must Have

  • Workspace Settings Action (Global dialog from a new menu item under the cog in the top-right)
  • File Viewer
  • Project Settings page
  • Global page (Global dialog from a new menu item under the “More” dropdown in the top-nav)

Events/Event modifications - Must Have

  • More data to the “status updated” event for pull requests, make sure we’re including all relevant context.

UI Modules - Should Have

  • File Editor
  • Code Annotation
  • PR Comment

App migration - Must Have

  • Some way for a Connect app to register a Forge app as it’s “replacement”.
  • Some kind of process to notify workspace admins that they have a Connect app installed that has a Forge replacement.
  • A link from the Connect app install listing to the relevant Forge app listing.

App migration - Should Have

  • A way to migrate a Marketplace listing for a current Connect app to a replacement Forge app.
6 Likes