* 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
* Adding tabindex to ImageUpload div wrapper in order to make it selectable
* Adding keyboard event handler to listen to Enter key stroke and trigger file upload selection
Co-authored-by: Keyan <34140557+huumn@users.noreply.github.com>
* show placeholder for hidden stackers in top
* top rewardability views
* make territory revenue idependent job
* monthly rewards and leaderboard on rewards pages
* fix earn reschedule
* add query for rewards leaderboard
* reduce likelihood of rewards racing with views
* fix earn and refine values views
Turbo zaps had different toast bodies so they weren't merged together. This gave stackers the option to undo these zaps out of order.
When zaps are undone out of order, the client cache can get in a bad state. Using the item id as a tag fixes that such that zaps for the same item will always get merged together.
This can be seen as a workaround for hacky zap undo code but I think it's also better UX so maybe we should do this anyway.
keyan
Keyan
ekzyis
JP Melanson