[DRAFT] Add Procedure ReinstallExtension to trigger Install Code from AL

[JohnnyUndercover]

This is a Draft because i think this is a hack and could be better solved by adding a possibility to trigger upgrade code (with DataTransfer) from AL Code.
But currently this seems to be the only way to trigger code that uses DataTransfer from AL.

Summary

Adds a new Procedure "ReinstallExtension" to Extension Management. The Procedure uninstalls and then installs the extension again. It also reinstalls the extensions that are dependent on the reinstalled extension.

By Installing the Extension the Install Codeunints of the extension are triggered.
Inside Install Codeunits we can use DataTransfer to move Data between Tables/Fields.
This is usefull if you have features that can be enabled by the user, but these features require some data beeing moved to new tables/fields. If we copy the Data using repeat until this can be very slow and time consuming. Accordin to the docs using DataTransfer instead, can result in a "~200x performance improvement".

Work Item(s)

Fixes #1659

[github-actions]

Issue #1659 is not valid. Please make sure you link an issue that exists, is open and is approved.

[nikolakukrika]

We are against this change.
If we need to enable the data transfer or triggering upgrade on the same version this must be done via platform and we need to define the slices propperly.

[nikolakukrika]

We do not want to introduce this kind of trigger/functionality in the app. Re-running the upgrade code is dangerous, it can lead to data corruption.

If the version has not changed there must not be upgrade.

If there is a huge need to do this, we have platform capabilities to trigger the upgrade even if the version has not changed. We can trigger the upgrade in place, we are doing this for the cloud migration.

Alternative is to increase the version of the app and to publish that one.
Another alternative is that you can run the data transfer now if the cloud migration is enabled, so if you are running this code during the cloud migration, it can be run via an action from the UI.

[JohnnyUndercover]

We do not want to introduce this kind of trigger/functionality in the app. Re-running the upgrade code is dangerous, it can lead to data corruption.

The upgrade code is not executed any more or less than it would be in the case of manually uninstalling and reinstalling the same version. Additionally, there are UpgradeTags to ensure that upgrade logic is not executed multiple times.

If the version has not changed there must not be upgrade.

Correct. But depending on setup parameters, an install routine can be executed.

If there is a huge need to do this, we have platform capabilities to trigger the upgrade even if the version has not changed. We can trigger the upgrade in place, we are doing this for the cloud migration.

Alternative is to increase the version of the app and to publish that one.
Another alternative is that you can run the data transfer now if the cloud migration is enabled, so if you are running this code during the cloud migration, it can be run via an action from the UI.

Providing a new app version would fundamentally contradict the idea, as the explicit goal is for the DataTransfer code to be triggered by the user.
I will try to describe the use case again:

Initial situation: User has installed the app with Feature A and B.

Problem:
A new app version is provided that adds Feature C as a replacement for Feature B.
Since using Feature C requires a change in the user's workflow, the user should be able to decide for themselves when to perform the upgrade from Feature B to Feature C.
For the upgrade, a large amount of data needs to be moved, so executing it with DataTransfer would be advantageous.

How can the user independently trigger the feature upgrade (with DataTransfer) from B to C?

Currently, there is no way to use code that utilizes DataTransfer outside of upgrade or install codeunits. This is where the ReInstall hacky logic comes into play.

Step-by-Step Process:
At the moment the Process could be something like this.

1. Initial Installation: A new app version containing Feature C and the upgrade logic is installed, but the actual feature upgrade from B to C is not executed yet.

2. State Management: A separate dependency app maintains an "Upgrade State" with values like:

   • "Not Performed" (initial state)
   • "Pending" (user has scheduled the upgrade)
   • "Planned" (upgrade is queued for execution)
   • "Performed" (upgrade completed)

3. User-Triggered Action: Users can initiate the upgrade through an action in the dependency app, which programmatically uninstalls and reinstalls the target app.

4. Conditional Upgrade Execution: During the reinstall process, the install codeunit checks the upgrade state and conditionally executes the Feature B→C migration using DataTransfer, then sets an UpgradeTag to prevent re-execution.

Because sometimes mermaid diagrams tell more than words:

Loading

graph TD
    A[New App Version Installed<br/>with Feature C + Upgrade Logic] --> B[Upgrade State: 'Not Performed'<br/>stored in Dependency App]
    
    B --> C[User Continues Using Feature B]
    
    C --> D{User Ready for<br/>Feature C?}
    D -->|No| C
    D -->|Yes| E[User Clicks Upgrade Action<br/>in Dependency App]
    
    E --> F[Set Upgrade State: 'Pending']
    F --> G[Programmatic Reinstall of App]
    
    G --> H[Install Codeunit Executes]
    H --> I{Check Upgrade State<br/>= 'Pending'?}
    
    I -->|No| J[Normal Install Process]
    I -->|Yes| K[Execute DataTransfer Logic<br/>Feature B → Feature C]
    
    K --> L[Set UpgradeTag<br/>to Prevent Re-execution]
    L --> M[Set Upgrade State: 'Performed']
    M --> N[User Now Uses Feature C]
    
    J --> O[Feature B Remains Active]
    
    style A fill:#e1f5fe
    style G fill:#ff6b6b,color:#ffffff
    style K fill:#fff3e0
    style N fill:#e8f5e8

But at the End, all this would not be necessary if we would be able to just run a Codeunit which is using DataTransfer from a UI Action. I Would love to see this inside the Feature Management, handled by the plattform and extensible by partners. If you promise that you are working on somthint like this, i will be happily close this draft ;)