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.
This registers the language Russian in the backend. Unfortunately, the
locations seem to be implemented with a hard coded attribute for each
language. 😞
We should refactor this.
@KapilJ your solution is right now the best solution, I think. Probably
the ideal solution would be if we could implement the `CreateComment`
resolver in such a way that it is doing eager loading of the
`comment->post->author` relationship and resolving a commment object
which has the required objects all set. Then you wouldn't have to
refetch all the stuff.
But I think this is OK for now 👍
- 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>
- disable button if form.reasonCategory is falsy
- extract valuesReasonCategoryOptions to global constant
- extract reasonCategoryOptions to created lifecycle hook to keep data()
clean and use map
- extract formSchema to components/utils and test
- remove validator from formSchema and validate based on "Deep Rules" https://github.com/yiminghe/async-validator#deep-rules
- Use v-model to update reasonCategory and reasonDescription
- default to error message in English from backend
- Update template slot to use new syntax
- Extract validations to the validations middleware to clean it up
- Remove resourceId since it throws an error in the mutation if the user
asks for it back, and the resourceId is returned in post/comment/user.id
- use writeTxResultPromise to benefit from automatic retries
- more descriptive variable naming
- extract cypher query to make db manipulation into script so that it
can be run from the command line, at least locally.
We use an unmaintained package called `activitystrea.ms` for the
activity pub middleware. Since the activity pub middleware is dead code
at the moment I suggest that we remove that package and disable all the
code that depends on the package.
When we get back to implement the ActivityPub spec for Human Connection I
would suggest to maintain this package `activitystrea.ms`, update the
dependencies there and re-enable and **test** the code of the activity pub
middleware.
