* 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
Reported by @napoly
In an integration test for a plugin, attempt to resolve a type provided by that plugin using `BTCPayServerTester`.
For example:
```
tester.GetService<MoneroRPCProvider>();
```
The type should be resolved successfully.
The type fails to resolve.
During the test run, the dotnet runtime attempts to load `MoneroRPCProvider` in the default load context (`AssemblyLoadContext.Default`). It locates the plugin assembly in the test directory and loads it there.
In contrast, when BTCPay Server loads a plugin, it creates a dedicated plugin load context, and the plugin’s `MoneroRPCProvider` is loaded inside that context. This results in two distinct `MoneroRPCProvider` types: one in the default context and one in the plugin context.
This PR forces the plugin context, during integration tests, to load the types it resolves into the default assembly context rather than its own. This prevents duplicate type definitions.
As a side effect, behavior may differ slightly between running BTCPay Server normally and running tests, but this should be acceptable in most cases.
Relevant discussion: #6851
The component UIExtensionPoint was injecting IEnumerable<IUIExtension>
and then filtering on those.
As the number of IUIExtension grows, this operation grows at O(n).
Now we use UIExtensionsRegistry instead which use lookups. O(1)
Reported by @napoly.
## Actual behavior
Two tests were created. When we would run the tests through the runner,
ASP.NET wouldn't find the registered view of the plugin.
## Expected behavior
The second test should works find, ASP.NET should properly find the
views of the plugin when there are more than one test in the same test
run.
## Cause
If we detected that a plugin assemly was already in the AppDomain, then
we were not loading the ApplicationParts of such assembly.
This wasn't the case for the first test run, but would be after.
The reason for initially doing this was that long time ago, we would
test plugins by referencing them from BTCPaySevrer project. But since
this is not how we are doing things anymore, I think it is safe to
remove this "Feature".
This feature was broken anyway since we started loading plugins in their
own context, but this wouldn't happen with the old way of referencing
plugins from BTCPayServer. (#6851)
The richtext box had an annoying bug: If you switch to code view, modify
the code then save, the changes would be ignored.
One had to switch back to preview mode prior to save. (See
summernote/summernote#94 for more details)
We were previously saving the rates in the database in a JSONB blob
column. However, the volume of data ise consequential enough for
provoking timeouts during update.
Due to how postgres works, this also create bloat in the database that
isn't cleaned immediately.
This PR fixes this issue by saving the cache in files instead.
If a user go to store A, then lose access to store A, any attempt to
browse the home page will return a 403 error.
The user would then get stuck, unable to select a new store until he
clears the cache.
