- As blocking is now reciprocal, we do not need another query, we can
use neo4j-graphql-js magic to query for a BLOCKED relationship between
the postAuthor and the currentUser
- at the moment, we have implemented blocked like we want the
blacklist/whitelistUserContent to be, with the exception that is should
not be both ways. If I blacklist a user's content, they still see my
content in their news feed.
The story of SearchInput.vue throws errors because of line 81, dateTime. What must be included to fix this?
The search results shown by the frontend are sometimes differnt from the response of the backend. It shows no results found though there are results incoming.
Tests are not implemented yet.
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.
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
}
}
```
- following @roschaefer's PR review suggestions
- simplify UpdatePost by using pinPost/unpinPost
- did not remove filtering because attempting to have two queries caused
problems as well to do with duplicate records, etc... and it's working
now
- at the moment, it is created as a property of Post, but will be
refactored to create a relationship[:PINNED] from the admin to the Post
- Co-authored-by: kachulio1 <jngugi88@gmail.com>
I think the validation for categories was too complex and the graphql
query 'PostEmotionsByCurrentUser' was erroneously allowed for
unauthenticated users.
