- for some reason RedisPubSub works locally, but with docker it tries to
connect to Redis and therefore it doesn't pass the build. PubSub is
imported from graphql-subscriptions which is a dependency of
apollo-server-express, and suitable for dev purposes.
- it's questionable whether this simplifies it or not, and actually adds
one line of code, but now it looks more similiar to the code in the
notifications query
- remove the code for subscriptions to Post as we won't implement this
at this time... I've created a new branch with the code that can be
built on later
- remove unused subscription path
- add possibility to use websockets uri for production env.
- we have introduced a better way to return all the info we want without
needing to make multiple database queries. It was introduced by
@roschaefer in the PR for the notifications query, but we hadn't
refactored markAsRead yet.
- Now that we are subscribing to notifications, we need to have the same
return info as the notification query.
- Co-authored-by: Tirokk <wolle.huss@pjannto.com>
- We want to publish when a notification occurs for a specific user, not
have the client poll the backend for ever user every minute.
- Co-authored-by: @Tirokk <wolle.huss@pjannto.com>
- Also, use original verifiedAt date for emails. These users only have
newly created accounts/emails because of our blunder. Their nodes
should reflect when they became members/verified their emails.
* 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>
We have to figure out if `mergeRels: true` is actually avoiding
duplicate relationships 🤔.
Before:
(l1)-[:IS_IN]->(l2)
(l1)-[:IS_IN]->(l3)
After:
(l1)-[:IS_IN]->(new)
(l1)-[:IS_IN]->(new)
- create command should be run with --date-format to be more human
readable, and --template-file to use our template instead of migrate's
default
- rename migrations
- rename createdAt to migratedAt to remove ambiguity
- do not merge relationships for Location nodes as we don't want to
create duplicate relationships
- use singular locationId as it's iterating one at a time
- having duplicate Location nodes in the production database blocks us
from adding a unique constraint, so that Locations are not created
which have the same id.
- 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
Implement a migration to merge duplicate user accounts with reactive
programming. Those duplicate user accounts existed, because around 40
users have decided to register again while we experienced a bug
related to normalized emails in our database.
* DRY schema stitching code
* Use same `.env` configuration file for cypress tests
That last part I couldn't improve a lot. I thought it might be possible
with cypress to import all files from a folder. But since it must be
browser compatible and our backend is not using webpack or anything,
it remains a goal unreached.
close#2773close#2774
