* Replace useInvoiceable with usePayment hook
* Show WebLnError in QR code fallback
* Fix missing removal of old zap undo code
* Fix payment timeout message
* Fix unused arg in super()
* Also bail if invoice expired
* Fix revert on reply error
* Use JIT_INVOICE_TIMEOUT_MS constant
* Remove unnecessary PaymentContext
* Fix me as a dependency in FeeButtonContext
* Fix anon sats added before act success
* Optimistic updates for zaps
* Fix modal not closed after custom zap
* Optimistic update for custom zaps
* Optimistic update for bounty payments
* Consistent error handling for zaps and bounty payments
* Optimistic update for poll votes
* Use var balance in payment.request
* Rename invoiceable to prepaid
* Log cancelled invoices
* Client notifications
We now show notifications that are stored on the client to inform the user about following errors in the prepaid payment flow:
- if a payment fails
- if an invoice expires before it is paid
- if a payment was interrupted (for example via page refresh)
- if the action fails after payment
* Remove unnecessary passing of act
* Use AbortController for zap undos
* Fix anon zap update not updating bolt color
* Fix zap counted towards anon sats even if logged in
* Fix duplicate onComplete call
* Fix downzap type error
* Fix "missing field 'path' while writing result" error
* Pass full item in downzap props
The previous commit fixed cache updates for downzaps but then the cache update for custom zaps failed because 'path' wasn't included in the server response.
This commit is the proper fix.
* Parse lnc rpc error messages
* Add hash to InvoiceExpiredError
* Render Rumble video in preview and posts
* Display Rumble video
* Remove workspace
* Add util function
* Use searchParam for id
* Update check for Rumble
* Update youtube match strings
* fix hostname conditions
---------
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
* @remindme bot support
support reminders via @remindme bot, just like @delete bot
* minor cleanup
* minor query cleanup
* add db migration
* various fixes and updates:
* hasNewNotes implementation
* actually return notification component in ui
* delete reminder and job on item delete
* other goodies
* refactor to use prisma for deleting existing reminder
* * switch to deleteMany to delete existing Reminders upon edit/delete of post to satisfy prisma
* update wording in form toast for remindme bot usage
* update wording in the push notification sent
* transactional reminder inserts and expirein
* set expirein on @delete too
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
* honor mutes when sending push notifications for:
* territory subscriptions
* mentions
* user subscriptions
Also, don't allow you to mute a subscribed user, or vice versa
* refactor mute detection for more code reuse
update mute/subscribe error messages for consistency
* variable rename
* move `isMuted` to shared user lib, reuse in user resolver and webpush
* update awards.csv
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* first pass of hashing user emails
* use salt
* add a salt to .env.development (prod salt needs to be kept a secret)
* move `hashEmail` util to a new util module
* trigger a one-time job to migrate existing emails via the worker
so we can use the salt from an env var
* move newsletter signup
move newsletter signup to prisma adapter create user with email code path
so we can still auto-enroll email accounts without having to persist the email address
in plaintext
* remove `email` from api key session lookup query
* drop user email index before dropping column
* restore email column, just null values instead
* fix function name
* fix salt and hash raw sql statement
* update auth methods email type in typedefs from str to bool
* remove todo comment
* lowercase email before hashing during migration
* check for emailHash and email to accommodate migration window
update our lookups to check for a matching emailHash, and then a matching
email, in that order, to accommodate the case that a user tries to login
via email while the migration is running, and their account has not yet been migrated
also update sndev to have a command `./sndev email` to launch the mailhog inbox in your browser
also update `./sndev login` to hash the generated email address and insert it into the db record
* update sndev help
* update awards.csv
* update the hack in next-auth to re-use the email supplied on input to `getUserByEmail`
* consolidate console.error logs
* create generic open command
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
* Allow deletion of wallet logs
* Refactor wallet logs client<>server glue code
* Use variant='link' and className='text-muted fw-bold nav-link' for clear & cancel
There is a bug though: 'clear' stays highlighted after modal is closed
* Include wallet in toast
* Delete logs on logout
* Fix ugly wallet name in confirm dialog
* Fix clear still highlighted after modal closed
* Only delete client wallet logs
* Fix ugly wallet name in toast
* Fix bad search and replace
* Use Wallet object as constant
* Also delete LNC logs on logout
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* first pass of a mute mgmt page, ported from subscription mgmt page pr
* adjust error message for mutes
* muted users -> muted stackers
* fix typo in component name
* env vars for polling intervals
add env vars for 4 different common polling intervals,
fast (1000), normal (30000), long (60000), extra long (300000)
use env vars in all `pollInterval` params to `useQuery`
* replace `setInterval`'s interval with `FAST_POLL_INTERVAL`
* first pass of a subscription management page under settings
* add tabs to settings ui
* NymActionDropdown
* update Apollo InMemoryCache to merge paginated list of my subscribed users
* various updates
* switch from UsersNullable to Users
* bake the nym action dropdwon into the user component
* add back fields to the user query
* `meSubscriptionPosts`, `meSubscriptionComments`, `meMute`
* Refetch my subscribed users when a user subscription is changed
* update user list to hide stats in the subscribed list users
* update my sub'd users fragment to remove unnecessary user fields
* memoize subscribe user context provider value to avoid re-renders
* use inner join instead of left join
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* throw error when unauthenticated
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
if `fetch` or `req.json` fails, catch those errors and return a default error to the user
if the res payload indicates error but doesn't return a `reason`, also return the same
default error message to the user
* Handle archived territories in territory form
* Use dedicated mutation
* Add sanity check for eternal territories
* Fix fields and cost ignored
* Remove no longer needed manual validation in upsertSub
* Remove founder check
* Always check if sub is archived
Using { abortEarly: false } now since previously, if no description was not given, we wouldn't detect if the sub was archived since validation would abort on empty descriptions.
Only on submission all fields would get validated but since we ignore archived errors during submission, the user would never see that the sub is archived before submission
+ the wrong mutation would run if archived is not already true before submission.
Hence, we need to validate all fields always.
There is currently still a bug where the validation does not immediately run but maybe this can be fixed by simply using validateImmediately on the Formik component.
* Fix archived warning not shown after first render
* Only create transfers if owner actually changes
* Reuse helper functions in lib/territory.js
* Rename var to editing
* Use onChange instead of validation override
* Run same validation on server for unarchiving
* Fix 'territory archived' shown during edits
* Use && instead of ternary operator for conditional query
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* Ignore if sub belongs to user during existence check
* Remove code no longer needed
* Fix territory edit
Territory edits were broken because validation failed for existing territories and if you edit an territory, it obviously already exists.
This commit fixes this by ignoring the territory that we're currently editing.
* Fix existence check using stale cache
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* Allow founders to transfer territories
* Log territory transfers in new AuditLog table
* Add territory transfer notifications
* Use polymorphic AuditEvent table
* Add setting for territory transfer notifications
* Add push notification
* Rename label from user to stacker
* More space between cancel and confirm button
* Remove AuditEvent table
The audit table is not necessary for territory transfers and only adds complexity and unrelated discussion to this PR.
Thinking about a future-proof schema for territory transfers and how/what to audit at the same time made my head spin.
Some thoughts I had:
1. Maybe using polymorphism for an audit log / audit events is not a good idea
Using polymorphism as is currently used in the code base (user wallets) means that every generic event must map to exactly one specialized event.
Is this a good requirement/assumption? It already didn't work well for naive auditing of territory transfers since we want events to be indexable by user (no array column) so every event needs to point to a single user but a territory transfer involves multiple users.
This made me wonder: Do we even need a table? Maybe the audit log for a user can be implemented using a view? This would also mean no data denormalization.
2. What to audit and how and why?
Most actions are already tracked in some way by necessity: zaps, items, mutes, payments, ...
In that case: what is the benefit of tracking these things individually in a separate table?
Denormalize simply for convenience or performance? Why no view (see previous point)? Use case needs to be more clearly defined before speccing out a schema.
* Fix territory transfer notification id conflict
* Use include instead of two separate queries
* Drop territory transfer setting
* Remove trigger usage
* Prevent transfers to yourself
ekzyis
Tom
SatsAllDay
itsrealfake
Keyan
keyan
Ben Allen