Fixes#6369, a regression introduced with#6188: Sending invite emails required a flag to be set, which defaulted to false. This fixes the code to explicitely set the flag and also defaults it to true (sending an invite email unless declared otherwise).
* Server: Make sending email optional when adding user
Closes#6158.
* Generate custom invite token and store it in user blob
Closes btcpayserver/app/#46.
* QR code for user invite
Closes#6157.
* Text fix
* Onboarding: Invite new users
- Separates the user self-registration and invite cases
- Adds invitation email for users created by the admin
- Adds invitation tokens to verify user was invited
- Adds handler action for invite links
- Refactors `UserEventHostedService`
- Fixes#5726.
* Add permissioned form tag helper
* Better way of changing a user's role
* Test fixes
* Server Users: More precise message when inviting users
This lets the admin who invited a new user know whether or not an email has been sent. If the SMTP server hasn't been set up, they need to share the invite link with the user.
* Onboarding: Invite new users
- Separates the user self-registration and invite cases
- Adds invitation email for users created by the admin
- Adds invitation tokens to verify user was invited
- Adds handler action for invite links
- Refactors `UserEventHostedService`
* Remove duplicate status message from views that use the wizard layout
* Auto-approve users created by an admin
* Notify admins via email if a new account requires approval
* Update wording
* Fix update user error
* Fix redirect to email confirmation in invite action
* Fix precondition checks after signup
* Improve admin notification
Send notification only if the user does not require email confirmation or when they confirmed their email address. Rationale: We want to inform admins only about qualified users and not annoy them with bot registrations.
* Allow approval alongside resending confirm email
* Use user email in log messages instead of ID
* Prevent unnecessary notification after email confirmation
* Use ApplicationUser type explicitly
* Fix after rebase
* Refactoring: Do not subclass UserRegisteredEvent
* Users list: Cleanups
* Policies: Flip registration settings
* Policies: Add RequireUserApproval setting
* Add approval to user
* Require approval on login and for API key
* API handling
* AccountController cleanups
* Test fix
* Apply suggestions from code review
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
* Add missing imports
* Communicate login requirements to user on account creation
* Add login requirements to basic auth handler
* Cleanups and test fix
* Encapsulate approval logic in user service and log approval changes
* Send follow up "Account approved" email
Closes#5656.
* Add notification for admins
* Fix creating a user via the admin view
* Update list: Unify flags into status column, add approve action
* Adjust "Resend email" wording
* Incorporate feedback from code review
* Remove duplicate test server policy reset
---------
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
* Store Settings feature with own table
* fix test
* Include the store settings to StoreRepository, remove caching stuff
Co-authored-by: nicolas.dorier <nicolas.dorier@gmail.com>
* 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>
* 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.
replaces #1591 and #1592 , closes#1571 Replaces the Currencies.txt to a json format which includes the networks too ( there is also a test to check now) Also makes CurrencyPair not depend on network and instead use CurrencyNameTable
* new feature: Wallet Receive Page
closes#965
* Conserve addresses by waiting till address is spent before generating each run
* fix tests
* Filter by cryptocode before matching outpoint
* fix build
* fix edge case issue
* use address in keypathinfo directly
* rebase fixes
* rebase fixes
* remove duplicate code
* fix messy condition
* fixes
* fix e2e
* fix
* simplify settings changed listening
Might as well use the Event aggregator to listen in on changes instead of the current complicated magic in the settings repo. This also reduces db calls( it sends the new settings through the event instead of fetching them again)
* add settings extension
* switch to old style but using event aggregator
