* Implement cypress tests
- Start implementation of cypress tests for pinned posts
* Test that Admin can pin a post
- Tests the process of an admin pinning a post
* Resolve failing tests
- Fix ordering of posts immediately after pinning posts by reloading page
- Check that tests are pinned posts are displayed first for role user
* Refactor to seperate the initialization
- Of the post data created in the database during setup
* Fix toaster test
* test(cypress): Add missing parts for pin feature
* docs(cucumber): Link to admin 🥒 folder
* Follow @mattwr18's suggestions
* test(backend): Order pinned posts like frontend
@mattwr18 I think this was a false negative.
Co-authored-by: Robert Schäfer <git@roschaefer.de>
- 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
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.
- it's good to return the pinnedAt date for ordering
- move test to a better describe block
- remove unneeded outdated variables from graphql/PostQuery UpdatePost
- fix indentation in Post.gql
- fix pinnedAt to return pinned.createdAt, not post.createdAt
Co-authored-by: Mike Aono <aonomike@gmail.com>
- 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>
- we had a silly serious bug by overwriting all attributes at the time
of UpdatePost
- tests in place to ensure we don't accidentally delete our createdAt
attribute
I think the validation for categories was too complex and the graphql
query 'PostEmotionsByCurrentUser' was erroneously allowed for
unauthenticated users.
@mattwr18 I prefer (I believe it's even best practice) that a delete
mutation should return the deleted object. If you run the delete
mutation again, it should return `null` because there is no object like
that anymore. That way the client knows if a delete mutation has changed
any state in the database.
Also I fixed another bug in the resolver. If your graphql mutation looks
like this:
```gql
mutation {
RemovePostEmotions(to:{ id:"p15"}, data:{emotion: angry}) {
from {
id
name
}
to {
id
title
}
emotion
}
}
```
Then you get errors because your resolver does not return the name for
the user or the title for the post anymore. Just use spread operator...
and it's fixed.
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.
