- this was making things more likely to fail from the frontend, we would
need to consider doing a db manipulation for users from the old alpha
who have user.name as null.
- it only protects against someone who bypasses our UI and sends a
message directly to the backend, but if they can do that we have bigger
problems.
- write tests for userMiddleware
- checks the functionality of nodes/locations middleware
- refactor to not allow users to update to remove their name
debatable whether we want that or not, but we do not allow users to
create accounts with no name, so we should be consistent, before we were
using neode to validate this, but we have are removing neode from
production code, so we must validate ourselves
- collate UpdateUser mutations to one
- Refactoring without tests makes it riskier
- Move some tests from resolver to middleware unit tests to live closer
to where the validation happens, remove duplicate tests
- DRY out code
We had this error in our neo4j pod recently:
```
2019-12-02 08:29:42.680+0000 ERROR Unable to schedule bolt session 'bolt-1018230' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.680+0000 ERROR Unable to schedule bolt session 'bolt-1018224' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.681+0000 ERROR Unable to schedule bolt session 'bolt-1018352' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.682+0000 ERROR Unable to schedule bolt session 'bolt-1018243' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
```
Apparently the default is 400 threads. So we must have a leak somewhere.
- update script
- use readTxResult for validateReview
- favor more verbose variables
- do not set review.closed as we close the report and the rule at the
moment is set to 'latestReviewUpdatedAtRules' rule, so it's clear the
last review must have been the one that closed the report
- Don't throw error if a report already exists since we use MERGE and
that does not create a new resource if it exists. That is tested at the
neo4j(database) level.
- We also have a test to make in reports.spec.js that no duplicate is
created to ensure we didn't make some error on our part.
- Fix some faulty logic in validateReview
- disable button if form.reasonCategory is falsy
- extract valuesReasonCategoryOptions to global constant
- extract reasonCategoryOptions to created lifecycle hook to keep data()
clean and use map
- extract formSchema to components/utils and test
- remove validator from formSchema and validate based on "Deep Rules" https://github.com/yiminghe/async-validator#deep-rules
- Use v-model to update reasonCategory and reasonDescription
- default to error message in English from backend
- Update template slot to use new syntax
- Extract validations to the validations middleware to clean it up
- Remove resourceId since it throws an error in the mutation if the user
asks for it back, and the resourceId is returned in post/comment/user.id
- use writeTxResultPromise to benefit from automatic retries
- more descriptive variable naming
- extract cypher query to make db manipulation into script so that it
can be run from the command line, at least locally.
I think the validation for categories was too complex and the graphql
query 'PostEmotionsByCurrentUser' was erroneously allowed for
unauthenticated users.
This commit takes all backend changes for signup and invite feature. I
was working on these features and removed the generated mutations for
type user along the way.
