givepraise / praise Goto Github PK

Ask @kristoferlund for details.

This does not look good:

Add

ID - Praise mongodb id
QUANTIFIER USER [X] - The "username" of the quantifier.

"Username":

1. Discord account name, or
2. Telegram account name, or
3. Ethereum address

Change

QUANT SCORE [X] -> SCORE [X]
TO -> TO USER ACCOUNT
FROM-> FROM USER ACCOUNT

The database connection parameters currently have to be duplicated in

/.env
/api/.env
/discord-bot/.env

Those params should only be in /.env.

Multiple calls to dotenv are allowed. Include top level .env from /api and /discord-bot.

Backend, data model and api:

• Allow this setting to be changed while quantifying: yes/no, true/false
• Data types:
  • Number
  • String
  • Textarea
  • Boolean
  • File

Frontend, settings interface:

• Generate form fields based on type
• Perform type checking

Frontend and backend, helper functions to get values with correct data types.

All api request parameters need to be validated against schema rules and sanitized from potentially harmful stuff.

Have a look at this article:
https://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html

And perhaps we will use this package:
https://www.npmjs.com/package/mongo-sanitize

Also, there is this package, not specifically for mongodb, but might be useful:
https://express-validator.github.io/docs/

Setting PRAISE_QUANTIFY_RECEIVER_PSEUDONYMS to true means that the identities of praise receivers should be hidden from quantifiers.

Real avatar images should be replaced with anonymous user icons. The UserAvatar component already supports hiding real image.

Currently the setting affect all pages, it should affect the quantifier screen: QuantifyPeriodReceiver/QuantifyPeriodReceiverPage.tsx

From discord chat
The mongo docs say you can only encrypt a freshly created db (not an existing, unencrypted db).
@Vyvy-vi have you started working on this yet, &/or have a plan yet?
kristofer — 01/31/2022
@graial Encryption is not something we have decided yet to implement. What would be the pros and cons?
graial — 01/31/2022
main pro of any encryption at rest for data is that if an attacker got in to the server, theyd have access to the the db/data, with encryption, they wouldnt be able to read/manipulate it
encrypting the db was a suggestion vy made on the notion I posted a couple weeks back
Main con is that it might be a pain to transfer the existing data over to the new encrpted one

https://docs.mongodb.com/manual/tutorial/configure-encryption/

As well as dialog to mark praise as duplicate.

Automate checking for build / lint errors in PRs before they can be merged.

Consider using a continuous integration tool (CircleCI or GitHub actions) and/or husky.

currently on http://68.183.14.23/

discord handle: divine_comedian#5493

quantifying praise I noticed that somehow I was assigned to quantify praise that was given to me. this should be impossible that a quantifiers quantify themselves.

Instead, it should only fetch a single page of praise data, the rest will be fetched as needed by the infinite scroll list.

• Making changes suggested in #47 PR review
• Cleaning up some of the bot code

(shifted from https://github.com/CommonsBuild/praise_frontend/issues/150 to here)

From @mattyg

Will there be a need to upgrade the schema of an existing databases? If so, we should include a migration script to update the settings schema but keeping their values. Perhaps using a migration tool like migrate-mongoose

Document in README that developers should install nvm to manage their node versions and either configure their shell to automatically switch node versions based on a .nvmrc file or run nvm use when entering the project directory to switch node versions.

If a quantifier is given some assignments for a period, an admin user can still remove their role as QUANTIFIER via the Quantifier Pool page.

This would leave the data in an improper state, where the quantifier still has a bunch of assignments, but is unable to complete them.

We should implement a back-end check and front-end dialog to prevent removal of active quantifiers from the pool, or handle re-assigning their assignments.

Generate documentation for the api package:

• swagger-jsdoc looks cool, see if we can use that
  • https://www.npmjs.com/package/swagger-jsdoc
• Ideally we would like generated docs to end up in the docs package @Vyvy-vi is setting up.

Move all hard coded strings from source files to the settings api.

Issue moved from praise_frontend, posted by @divine-comedian.

As an admin I create a new quantification period and I attempt to assign quantifiers to it

when I click the button I automatically it fails with a status code 500

If the setting PRAISE_QUANTIFY_DUPLICATE_PRAISE_PERCENTAGE is modified, it will cause historical praise score calculations to reflect the updated setting.

Do we want historical praise score calculations to change if settings are updated? If necessary, we can implement one of the solutions outlined below to ensure historical praise calculations remain static.

Options

• store praise score calculation in db, based on the settings at the time of calculation, rather than re-calculating on every fetch
• store settings history in db, calculate praise based on settings at the time of praise given, rather than current settings