- add hasBlocked query to check if userA initiated the blocking and, if
true, only them to unblock userB.
- add cypress tests to make sure we don't break this in the future.
reason: Rosie.js does not support promises. So for the time being, we
shall not use more than one `after` callback and we shall not use
buildList as it does not return a `Promise.all([])`. We have to ask the
maintainers of Rosie.js if they accept the breaking change of returning
a Promise always.
- 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.
