I had a chat with our moderator Daniel. He asks us to remove dots from
gmail accounts. He finds it more consistent and he has no problem to
write a mail to a gmail address without dots. He is OK to save the
email address different from how a user memorizes it.
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
```
- I wanted to trigger a build, since we had issues with our build server
today. I think this naming is more in the direction we want to go,
though. Maybe it could be makeShoutsPublic as @alina-beck used for the
translation keys... what do you think @kachulio
A query such as `{ notifications }` would return `null` for Locations
with a missing translation, e.g. `nameRU`. This would not happen for
queries implemented by `neo4j-graphql-js` because they nullify all
missing attributes automatically.
- there should only ever be one Donations node to start off with, if
that changes in the future for some reason, then we'd need to look into
changing the match to something that makes more sense.
@mattwr18 vue-apollo rocks! Taking the time to study the docs is a
rewarding investment.
My first idea was to cache the `unreadNotificationsCount` with Vuex.
But the docs of apollo even suggest to use apollo's local state as a
complete replacement of Vuex:
https://vue-apollo.netlify.com/guide/local-state.html
Then I further investigated why the updated `NOTIFIED` objects won't
update the notification counter. Turns out: They don't have an ID and
the computed property didn't fire when the notifications array would
change. I fixed both in this commit and yes, it works as expected.
No additional code required 💪
- Remove package-lock.json because we are using yarn
- Remove every instance of graphql-requests as the backend doesnt use it anymore
- Remove graphql-request dependancy from the backend
- Update scripts for running tests in package.json and remove the unused scripts
- Update travis.yml to run the new test scripts
