* Added the enable button on disabled plugins
* Added the disable function and button for installed plugins
* Changes based on the coderabbitai comments
* Removed markers and added the disable in the same if block as the unistall
* Hide the uninstall button when plugin is queued for enabling
* Removed the duplicate enale function
* Removed the disable button for installed plugins
* Removed the disableplugin functions as they are no longer needed
* Trigger CI pipeline after dotnet restore
* reverted the git ignore
* Fix: Plugin updates do not work
* Offer install on disabled plugins when different version
This will:
* Clear any previous pending actions of a plugin if you click uninstall
* Show the plugin version that was disabled
* Show an update button on disabled plugins instead of install
* if a plugin is scheduled to be installed/updated, it will show which version was scheduled to be updated. If a newer version if available than the scheduled one, it will show an option to switch to that
* Ensure disabled plugins don't get loaded
* View fixes
---------
Co-authored-by: d11n <mail@dennisreimann.de>
* Editorconfig: Add space_before_self_closing setting
This was a difference between the way dotnet-format and Rider format code. See https://www.jetbrains.com/help/rider/EditorConfig_Index.html
* Editorconfig: Keep 4 spaces indentation for Swagger JSON files
They are all formatted that way, let's keep it like that.
* Apply dotnet-format, mostly white-space related changes
* Automated Transfer processors
This PR introduces a few things:
* Payouts can now be directly nested under a store instead of through a pull payment.
* The Wallet Send screen now has an option to "schedule" instead of simply creating a transaction. When you click on schedule, all transaction destinations are converted into approved payouts. Any options relating to fees or coin selection are discarded.
* There is a new concept introduced, called "Transfer Processors". Transfer Processors are services for stores that process payouts that are awaiting payment. Each processor specifies which payment methods it can handle. BTCPay Server will have some forms of transfer processors baked in but it has been designed to allow the Plugin System to provide additional processors.
* The initial transfer processors provided are "automated processors", for on chain and lightning payment methods. They can be configured to process payouts every X amount of minutes. For on-chain, this means payments are batched into one transaction, resulting in more efficient and cheaper fees for processing.
*
* fix build
* extract
* remove magic string stuff
* fix error message when scheduling
* Paginate migration
* add payout count to payment method tab
* remove unused var
* add protip
* optimzie payout migration dramatically
* Remove useless double condition
* Fix bunch of warnings
* Remove warning
* Remove warnigns
* Rename to Payout processors
* fix typo
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
* Plugins flexibility PR
* Makes the BTCPayServerOptions.LoadArgs async to support Plugin hooks and actions
* relax the private set modifiers in the BTCPayNetwork
* Separate IPluginHookService from PluginService to reduce dependencies on DI
* fix some small bugs around image path
* Fix bug with new dbreeze migration where data dir was incorrect
* Update BTCPayServer/Plugins/PluginHookService.cs
Co-authored-by: rockstardev <5191402+rockstardev@users.noreply.github.com>
* Update BTCPayServer/Plugins/PluginHookService.cs
Co-authored-by: rockstardev <5191402+rockstardev@users.noreply.github.com>
Co-authored-by: rockstardev <5191402+rockstardev@users.noreply.github.com>
* More Options refactoring
Continues refactoring config classes to use the propert Options pattern where possible.
DataDirectories and DatabaseOptions are now configured the Options pattern and the BTCPayOptions is now moved alongside the other config setup
* Move COnfigure logic for Options to the Startup
This allows plugins to create custom dbcontexts, which would be namespaced in the scheme with a prefix. Migrations are supported too and the table would be prefixed too
Almost an exact replica of https://developer.wordpress.org/plugins/hooks/
This will allow plugins to extend specific points in business logic, such as validation, invoice payload changes, etc
* Plugins: Load plugins by order, aesthetic plugin dependency system
Introduces plugins loading in order of installation, BTCPay itself shows up as a system plugin, and that plugins can define other plugins as dependencies.
* use a proper type for plugin dependencies
* rebase fixes
* message when cannot install
This allows external integrations ( btcpay docker fragments) to highlight specific plugins as recommended to be installed. Also moved the remote option to a config option instead of a url query param to avoid messy situations where users could get deceived with a generated url. The dockerfiles also have an additional csproj to build and the plugin dir was renamed correctly from extensions to plugins
* BTCPay Extensions Part 2
This PR cleans up the extension system a bit in that:
* It renames the test extension to a more uniform name
* Allows yo uto have system extensions, which are extensions but bundled by default with the release (and cannot be removed)
* Adds a tool to help you generate an extension package from a csproj
* Refactors the UI extension points to a view component
* Moves some more interfaces to the Abstractions csproj
* Rename to plugins
