[GH-ISSUE #64] Implement Uninstallation/Deletion of Configuration Modules #17

New issue

Open

opened 2026-03-03 11:58:25 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 11:58:25 +03:00

Owner

Originally created by @olegprivate on GitHub (Jul 22, 2025).
Original GitHub issue: https://github.com/finmars-platform/finmars-core/issues/64

Originally assigned to: @falendary on GitHub.

Is your feature request related to a problem?
The current system provides a way to install configuration modules from the marketplace or create them manually. However, there is no corresponding functionality to uninstall or delete these modules once they are no longer needed. This can lead to a cluttered configuration and makes system cleanup impossible without manual database intervention.

Describe the solution you'd like
We propose introducing an uninstallation feature for configuration modules. This feature must include a critical dependency check to prevent accidental data corruption. If a module is in use by other entities, the user should be warned and given clear options on how to proceed with those dependent entities.

User Story
As a workspace administrator, I want to be able to delete a configuration module that I no longer need. If the module is being used by existing entities, I want to be warned and given the choice to either delete the dependent entities or make them read-only, so that I can manage my system configuration safely and effectively.
If there are other configuration modules that are dependent on the module - give a warning and propose to uninstall them as well.

Acceptance Criteria

Initiation of Uninstallation
Given a user is viewing an installed configuration module.
Then a "Uninstall/Delete" button should be visible.
Dependency Check and Warning
Given the user clicks the "Uninstall/Delete" button.
Then the system must perform a check to identify any entities and other modules that are dependent on this configuration module.

If no dependent entities are found:

A confirmation modal should appear: "Are you sure you want to delete this configuration module? This action cannot be undone." with "Confirm" and "Cancel" buttons.

Upon confirmation, the module is deleted, and the user is notified of the successful deletion.

If dependent entities are found:

A warning modal must appear with the following information:

Message: "This configuration module is currently in use by [X] entities. Deleting the module will affect these entities." (where [X] is the number of dependencies).

User Choices: The user must be presented with the following options for handling the dependent entities:

"Uninstall all [X] dependent modules along with the module."

"Delete all [X] dependent entities along with the module."

"Mark all [X] dependent entities as read-only."

"Cancel"

Handling Dependent Entities
Option 1: Delete Dependent Entities

Given the user chose to "Delete all [X] dependent entities".

When they confirm the action (e.g., by clicking a final "Delete All" button).

Then all dependent entities are deleted from the system.

And the configuration module itself is deleted.

And a success notification is displayed to the user.

Option 2: Mark Dependent Entities as Read-Only

Given the user chose to "Mark all [X] dependent entities as read-only".

When they confirm the action.

Then all dependent entities are flagged as read-only. Any UI interaction that allows for editing or deleting these individual entities should be disabled.

And the configuration module itself is deleted.

And a success notification is displayed to the user.

Technical Investigation
To Do: Before full implementation, developer SZ needs to investigate and confirm the behavior of entities (specifically TTYPES and InstrumentTypes) after their parent configuration is removed.

Question to answer: Can an entity's form still be displayed correctly if the entity is marked as read-only but its defining configuration is gone? The implementation path for the "read-only" feature depends on this investigation.

Originally created by @olegprivate on GitHub (Jul 22, 2025). Original GitHub issue: https://github.com/finmars-platform/finmars-core/issues/64 Originally assigned to: @falendary on GitHub. **Is your feature request related to a problem?** The current system provides a way to install configuration modules from the marketplace or create them manually. However, there is no corresponding functionality to uninstall or delete these modules once they are no longer needed. This can lead to a cluttered configuration and makes system cleanup impossible without manual database intervention. **Describe the solution you'd like** We propose introducing an uninstallation feature for configuration modules. This feature must include a critical dependency check to prevent accidental data corruption. If a module is in use by other entities, the user should be warned and given clear options on how to proceed with those dependent entities. **User Story** As a workspace administrator, I want to be able to delete a configuration module that I no longer need. If the module is being used by existing entities, I want to be warned and given the choice to either delete the dependent entities or make them read-only, so that I can manage my system configuration safely and effectively. If there are other configuration modules that are dependent on the module - give a warning and propose to uninstall them as well. **Acceptance Criteria** 1. Initiation of Uninstallation Given a user is viewing an installed configuration module. Then a "Uninstall/Delete" button should be visible. 2. Dependency Check and Warning Given the user clicks the "Uninstall/Delete" button. Then the system must perform a check to identify any entities and other modules that are dependent on this configuration module. If no dependent entities are found: A confirmation modal should appear: "Are you sure you want to delete this configuration module? This action cannot be undone." with "Confirm" and "Cancel" buttons. Upon confirmation, the module is deleted, and the user is notified of the successful deletion. If dependent entities are found: A warning modal must appear with the following information: Message: "This configuration module is currently in use by [X] entities. Deleting the module will affect these entities." (where [X] is the number of dependencies). User Choices: The user must be presented with the following options for handling the dependent entities: "Uninstall all [X] dependent modules along with the module." "Delete all [X] dependent entities along with the module." "Mark all [X] dependent entities as read-only." "Cancel" 3. Handling Dependent Entities Option 1: Delete Dependent Entities Given the user chose to "Delete all [X] dependent entities". When they confirm the action (e.g., by clicking a final "Delete All" button). Then all dependent entities are deleted from the system. And the configuration module itself is deleted. And a success notification is displayed to the user. Option 2: Mark Dependent Entities as Read-Only Given the user chose to "Mark all [X] dependent entities as read-only". When they confirm the action. Then all dependent entities are flagged as read-only. Any UI interaction that allows for editing or deleting these individual entities should be disabled. And the configuration module itself is deleted. And a success notification is displayed to the user. 4. Technical Investigation To Do: Before full implementation, developer SZ needs to investigate and confirm the behavior of entities (specifically TTYPES and InstrumentTypes) after their parent configuration is removed. Question to answer: Can an entity's form still be displayed correctly if the entity is marked as read-only but its defining configuration is gone? The implementation path for the "read-only" feature depends on this investigation.