* Fix formatting in bootstrap.css
This looks like it got introduced when resolving a merge conflict.
* Fix typos in views
* Fix semibold style definition
* Improve and unify page headers
* Altcoin test fixes
* Update BTCPayServer/Views/Apps/UpdateCrowdfund.cshtml
Co-authored-by: Andrew Camilleri <evilkukka@gmail.com>
* Update BTCPayServer/Views/Apps/UpdateCrowdfund.cshtml
Co-authored-by: Andrew Camilleri <evilkukka@gmail.com>
* Fix missing store name in pairing view
* Fix CanUsePairing test
* Bump header navigation font size
* Use partial tag instead of Html.PartialAsync in views
As suggested by @nicolasdorier. These are equivalent, see details [here](https://docs.microsoft.com/en-us/aspnet/core/mvc/views/partial?view=aspnetcore-3.1#partial-tag-helper).
* Fix docs link
As in #2432.
* Update BTCPayServer/Views/Wallets/SignWithSeed.cshtml
Co-authored-by: britttttk <39231115+britttttk@users.noreply.github.com>
* Update BTCPayServer/Views/Wallets/WalletSendVault.cshtml
Co-authored-by: britttttk <39231115+britttttk@users.noreply.github.com>
* Update BTCPayServer/Views/Wallets/WalletTransactions.cshtml
Co-authored-by: britttttk <39231115+britttttk@users.noreply.github.com>
Co-authored-by: Andrew Camilleri <evilkukka@gmail.com>
Co-authored-by: britttttk <39231115+britttttk@users.noreply.github.com>
* UI: Consistent spacing on maintenance view
* UI: Empty states for apps, stores and wallets
* UI: Empty state for file storage
* UI: Toggle invoice selection in list on row click
* Update ChromeDriver
* Fix selector in payjoin test
fixes#1958
Adds 2 new options:
* Do not allow stores to use the email settings of the server. Instead, they would need to fill in the email settings in their own store
* Do not allow user creation through the API unless you are an admin.
Both are opt-in and turned off by default.
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
* 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
Adds a warning to configure the e-mail server before "Requires a confirmation mail for registering" checkbox can be checked if e-mail server is not configured.
close#1889
* 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
* Allow disabling notifications per user and disabling specific notifications per use
closes#1974
* Add disable notifs for all users
* fix term generator for notifications
* sow checkboxes instead of multiselect when js is enabled
* remove js dependency
* fix notif conditions
* This refactors the email sending so that all the logic related to users and emails are now contained in one location.
* The Reset password screen has been updated from its ugly plain self to use the same layout as the login.
* An admin can now create a new account without specifying a password. A link is generated that can be given to the intended user to configure the password. If emails are configured, it also sends an email
* An admin can now create accounts that still require the user to verify their if the setting is enabled from the server settings. A link is generated that can be given to the intended user to configure the password. If emails are configured, it also sends an email.
* The above features can be used in conjunction: An email will have to verify their email through a link. Once verified, the user is redirected to setting the password.
* When an email has been verified OR a password has been set, users are now redirected to the login page with the email filled in and a success status message shown instead of a dedicated thank you page.
