If an underlying toast finished, an empty toast that automatically immediately hides was dispatched to end the flow ("end flow hack").
If this empty toast had the same tag, the code marked the top toast as hidden even though it was not hidden.
This meant that during render, the animation-delay for the top toast (which was already rendered) was added again, leading to a progress bar jump.
This is fixed by no longer using this "end flow hack" where a toast is dispatched but a dedicated function to end flows.
* 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>
* Generate API key in settings
* Check x-api-key for GraphQL API requests
* Don't fallback to cookie if x-api-key header was provided
* Select all session fields
* Fix error if API key not found
* Fix style in settings via form-label className
---------
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>
* Don't hide self in top even if hidden
* Also don't hide self in top cowboys
* only use anon icon for anon stuff
---------
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
Co-authored-by: keyan <keyan.kousha+huumn@gmail.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
keyan
ekzyis
Keyan
benalleng
Felipe Bueno
austinkelsay
Satoshi Nakamoto
JP Melanson