- return Claim instead of setting more properties on relationship
REPORTED
- use readTransaction for query to benefit from autmatic retries, follow
neo4j suggestion
- use map instead of forEach https://codeburst.io/javascript-map-vs-foreach-f38111822c0f
- We have been using http requests in our set up in this file, which can
be avoided. We are not trying to test that the report/review workflow
works properly here, we are trying to test that if a resource was
reported, and then disabled, some conditions are true. Certainly, we
will have tests that check that the report, review workflow works as
expected.
Since we decided to open Human Connection for public registration, we
don't need to create artificial shortage of signups. The original
intention here was too:
1. Grow the network slowly and under control
2. Create an incentive for users to invite their friends
Point 2 is now obsolete, everyone can signup herself. Point 1 is based
on the (seemingly) wrong assumption that there will be a "run" on the
network if we open it for public registration. Our growth was fairly
stable so far.
Ideally we would not have this inconsistent edge case that we filter
through the user type. Much better would be a graphql query like:
```graphql
{
User(filter: { primary_email: { email: "something@example.org" } }) {
id
name
slug
}
}
```
We need the order input types for our admin features.
This is a potential DOS vulnerability: Ordering the tags by taggedCount
might lead to very expensive cypher statements.
Apparently, `neo4j-graphql-js` *replaces* the schema partly. When we use
join models like `EMOTED`, `neo4j-graphql-js` puts in a join model with
the two names of the connected types.
I deprecated the debug flags myself here:
https://github.com/neo4j-graphql/neo4j-graphql-js/pull/288
You can now debug the queries run by `neo4j-graphql-js` by starting
the backend like this:
```bash
DEBUG=neo4j-graphql-js yarn run backend
```
