Commit Graph

3 Commits

Author SHA1 Message Date
ekzyis a6713f9793
Account Switching (#644)
* WIP: Account switching

* Fix empty USER query

ANON_USER_ID was undefined and thus the query for @anon had no variables.

* Apply multiAuthMiddleware in /api/graphql

* Fix 'you must be logged in' query error on switch to anon

* Add smart 'switch account' button

"smart" means that it only shows if there are accounts to which one can switch

* Fix multiAuth not set in backend

* Comment fixes, minor changes

* Use fw-bold instead of 'selected'

* Close dropdown and offcanvas

Inside a dropdown, we can rely on autoClose but need to wrap the buttons with <Dropdown.Item> for that to work.

For the offcanvas, we need to pass down handleClose.

* Use button to add account

* Some pages require hard reload on account switch

* Reinit settings form on account switch

* Also don't refetch WalletHistory

* Formatting

* Use width: fit-content for standalone SignUpButton

* Remove unused className

* Use fw-bold and text-underline on selected

* Fix inconsistent padding of login buttons

* Fix duplicate redirect from /settings on anon switch

* Never throw during refetch

* Throw errors which extend GraphQLError

* Only use meAnonSats if logged out

* Use reactive variable for meAnonSats

The previous commit broke the UI update after anon zaps because we actually updated item.meSats in the cache and not item.meAnonSats.

Updating item.meAnonSats was not possible because it's a local field. For that, one needs to use reactive variables.

We do this now and thus also don't need the useEffect hack in item-info.js anymore.

* Switch to new user

* Fix missing cleanup during logout

If we logged in but never switched to any other account, the 'multi_auth.user-id' cookie was not set.

This meant that during logout, the other 'multi_auth.*' cookies were not deleted.

This broke the account switch modal.

This is fixed by setting the 'multi_auth.user-id' cookie on login.

Additionally, we now cleanup if cookie pointer OR session is set (instead of only if both are set).

* Fix comments in middleware

* Remove unnecessary effect dependencies

setState is stable and thus only noise in effect dependencies

* Show but disable unavailable auth methods

* make signup button consistent with others

* Always reload page on switch

* refine account switch styling

* logout barrier

---------

Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: k00b <k00b@stacker.news>
2024-09-12 13:05:11 -05:00
ekzyis d237861ff5
Use module path aliases (#938)
* Use module path aliases

* fix broken refactor

* path mapping for svgs, style, and remaining places (bonus: lose babel dep)

---------

Co-authored-by: keyan <keyan.kousha+huumn@gmail.com>
2024-03-19 19:37:31 -05:00
ekzyis b379e7467f
Territory transfers (#878)
* 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
2024-03-05 13:56:02 -06:00