feat: verified icon in usernames

[danitrod]

PR Checklist

• - Latest master branch merged
• - PR title descriptive (can be used in release notes)

PR Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Adding verified icon to usernames in howto listings, howto pages, howto comments, events, research listings and research pages.

The approach chosen was to create a fetchAllVerifiedUsers method in the userStore, which queries the database for all users who meet the badges.verified == 1 condition and stores the list in a verifiedUsers prop. Based on that list, each component that displays usernames basically checks if the username is on the list to display a badge along.

Note: I changed the value type of badges.verified from boolean to number, having the number be 0 or 1. The reason is that boolean was causing problems with Dexie as booleans are not indexable (ref: https://stackoverflow.com/a/56661425/10736715). I added a comment explaining this in the model definition.

Git Issues

Closes #1163

[github-actions]

Visit the preview URL for this PR (updated for commit 27bf097):

https://onearmy-next--pr1205-verified-everywhere-qog5kwt8.web.app

_{(expires Sat, 19 Mar 2022 00:34:51 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[thisislawatts]

👋 @danitrod would you be able to rebase this PR to resolve merge conflicts?

[danitrod]

Sure @thisislawatts, done!

[cypress]

---

Test summary

70 • 0 • 0 • 0 • 2

---

Run details

Project	onearmy-community-platform
Status	Passed
Commit	5658585
Started	Oct 21, 2021 12:20 AM
Ended	Oct 21, 2021 12:28 AM
Duration	07:30 💡
OS	Linux Ubuntu - 20.04
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	sign-up.spec.ts		1
1	[Sign-up - new user] > sign in as new user
	sign-in.spec.ts		1
1	[Sign in] > [By Anonymous]

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[danitrod]

I see tests are failing, will have a look at that later today

[danitrod]

Alright, looks like all set now!

[thisislawatts]

question: Can we move the verified state to the HowTo document rather than perform this look up?

[danitrod]

I don't recall any specific reason why I did this, it's been a while but maybe I just didn't think it through enough. If we move this logic to the store and have the verified state in every HowTo doc, it would certainly be a lot more efficient and only perform the search once 😅

[thisislawatts]

@danitrod I missed the original conversation around this feature.

Did we consider how fetchAllVerifiedUsers may affect the charges incurred by the Project? I understand that Firebase charges for each read operation on a record.

So this change would a new query of N records to the following routes:

1. Events listing
2. Howto listing
3. An individual howto page
4. Research listing
5. Individual research page

Things I either don't know or understand:

1. FireBase caching means we can make repeated queries to the DB without incurring additional charges
2. There are only a low number of verified users so this is not a significant issue
3. This approach has already been approved with full awareness of the cost implications

[danitrod]

@danitrod I missed the original conversation around this feature.

Did we consider how fetchAllVerifiedUsers may affect the charges incurred by the Project? I understand that Firebase charges for each read operation on a record.

So this change would a new query of N records to the following routes:

1. Events listing

2. Howto listing

3. An individual howto page

4. Research listing

5. Individual research page

Things I either don't know or understand:

1. FireBase caching means we can make repeated queries to the DB without incurring additional charges

2. There are only a low number of verified users so this is not a significant issue

3. This approach has already been approved with full awareness of the cost implications

I don't have the basis to answer that right now as well, would have to study a bit more on how Firebase works. I don't remember if I talked with Chris about the implications on charges for this logic. Sorry, been some rough few months over here. Hopefully at the beginning of next year I'll be able to dedicate some more time into the project and help figuring this out.

[thisislawatts]

Thanks for the speedy response @danitrod, of course look after yourself first. This discussion can wait 🤗

[chrismclarke]

I have a good feeling this will finally be the week to unblock this PR!
As discussed on the calls and slack message last week, the blocking issue on this was how best to keep a shortlist of all user badges, as querying across all users is both tricky and inefficient. This is a common problem so decided best to come up with a general solution the make it easier for storing similar aggregations, via an aggregations db endpoint and set of backend functions

This just leaves a few small tasks

• Add db bindings for aggregations system ( Feat/db aggregations #1446)
• Resolve conflicts (mostly just minor import issues)
• Small refactor to point to aggregations endpoint
• Test and release

I'm working on the DB bindings now and will link the relevant PR when open