* Refactor how we handle and validate LN ConnectionStrings
* Migrate existing connection string to Internal Node if they are the same. Cleanup some obsolete fields
* Fix typos, remove duplicated method
* Add a InternalNodeRef to LightningSupportedPaymentMethod
* Introduce Additional Data to Store Blob and move obsolete props to migration
* Fixes and tests
* Small adjustements to prevent tracking too many objects
Co-authored-by: nicolas.dorier <nicolas.dorier@gmail.com>
* Remove only dependency on Dbriize (TextSearch in new invoice column)
* Switch to table for invoice text search
* Adding missing using after rebase
* Removing database migration in preparation for refresh
* Database Migration: Adding InvoiceSearchData
* Refactoring InvoicesRepository to make AddToTextSearch static and non-async
Operation as async is too expensive for simple filtering and AddRange
* Renaming InvoiceQuery property to Take
More inline with what property does by convention, Take is used in conjuction with Skip
* Refactoring SettingsRepository so update of settings can happen in another context
* Adding DbMigrationsHostedService that performs long running data migrations
* Commenting special placing of MigrationStartupTask
* Simplifying code and leaving comment on expected flow
* Resolving problems after merge
* Database Migration: Refreshing database migration, ensuring no unintended changes on ModelSnapshot
Co-authored-by: rockstardev <rockstardev@users.noreply.github.com>
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
* GreenField: Notifications API
This refactors notifications so that we dont have a bunch of duplicated direct access to db contexts in controllers and then introduces new endpoints to fetch/toggle seen/remove notifications of the current user.
* add tests + docs
* fix test
* pr changes
* fix permission json
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
