Items with type topup have a price = null and hence not even the property set (ignored in JSON). This needs to be handled in the temlate, otherwise this exception occurs:
```
An unhandled exception was thrown by the application.
System.InvalidOperationException: Nullable object must have a value.
at AspNetCoreGeneratedDocument.Views_Shared_Crowdfund_Public_ContributeForm.<>c__DisplayClass24_0.<<ExecuteAsync>b__0>d.MoveNext()
```
* Pluginify on chain wallet setup
This PR fixes a few logical points in the wallet setup flow to allow more extensive plugin flexibility; It also fixes an issue when building plugins that requires an Altcoin config profile. Here is an example showcasing the Liquid+ plugin using this to enforce that it is a hot wallet (a requirement it has) and that import to RPC is always set, and a new option that is used to configure the wallet further https://i.imgur.com/pDPQ73v.gif
* Update BTCPayServer/Controllers/UIStoresController.Onchain.cs
* update nbx
* Add What's New in v1.10.0
* Update BTCPayServer/Views/UIStores/Dashboard.cshtml
Co-authored-by: B <102448109+Bas02@users.noreply.github.com>
---------
Co-authored-by: B <102448109+Bas02@users.noreply.github.com>
* Show correct array regardless of size
fixes#4890
* Email provided to pos form was not forwarded to form
fixes#4810
* Make invoice receipt url redirect to the invoice redirect url if receipt is not enabled
When setting up a default email rule upon invoice settlement, you would link to the receipt page naturally. However, if using the payment requests, receipts are disabled as the payment request itself is the receipt. This commit makes the receipt url redirect to the invoice redirect url if available, and in the case of payment requests, it would mean the receipt url is the payment request url. fixes#4895
* Set the email address in the form when configured in the payment request
* fix pay request email copy
* fix payouts nav link
fixes#4788
* Update BTCPayServer/Views/UIPaymentRequest/EditPaymentRequest.cshtml
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
---------
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
I came across this while debugging #4889. This does not actually fix it, but it fixes an inconsistence in the casing of the parameter name.
However, I think the original issue is a caching problem in the browser. I was able to reproduce it on first load, after reloading the page once more it works as intended. The weird thing is: even though the values are correct on first load (verified via debugger), the `choiceKey` for the first item is set incorrectly to an integer value.
