This is a curl request from a folder where I have a file `avatar.jpg`:
```
curl localhost:4000/ \
-F operations='{ "query": "mutation($id: ID!, $file: Upload) { UpdateUser(id: $id, avatarUpload: $file) { id name avatar } }", "variables": { "id": "u3", "file": null } }' \
-F map='{ "0": ["variables.file"] }' \
-F 0=@avatar.jpg
```
It uploads the avatar to the public folder. We should
* Write tests
* Change the `user.avatar` url and send it to `/api` in the frontend
@ulfgebhardt: The reason why the test case was failing is pretty
obvious. You forgot to create a user that you want to update. If there
is no user to update, then you get an empty response.
@ulfgebhardt: I moved the spec also in the right directory. You're
testing resolvers, so that's where I moved the `.spec` file.
@ulfgebhardt @mattwr18 @tirokk
Here's how I imagined the data validation middleware. If we roll our own
input validations I would suggest to put them all in one place.
@ulfgebhardt this commit is a great example of how tests can speed you
up: Since I can rely on existing tests, I don't have to check the validations
manually. With tests you can refactor with confidence! 👍
See:
https://github.com/Human-Connection/Human-Connection/pull/478/files#r281267486
> We found the reason for it: If you have an exclamation mark in the schema e.g.
> email! and the response would e.g. expect the email for each User object, and
> the server does not have an email for the client, then the entire User object
> gets nullified.
- due to changes made to comments factories, which caused failures
- to use new custom CreateComment resolver syntax to relate a comment to post by passing in the postId
Note that we don't create duplicate notifications. I made use of the behaviour
of XSS-middleware: It removes all css classes from `<a>` anchors. Because
notifications rely on a css class `mention` which gets removed in a later
middleware, this gives us a nice behaviour for re-notifications without creating
duplicates. The downside is that it creates dependencies between middlewares and
it's not that obvious at all.
cc @mattwr18 @ulfgebhardt @appinteractive @Tirokk
Implemented suppression of "publicKey", now commented out for testing approach.
Use port 4001 for querying, but forgot that I have to generate the user on the same port, before I can query it with generated "publicKey".
Do this in next commit.
