Andre Löffelmann comments

Results 28 comments of


                                            Andre Löffelmann

Filters of `@authorization` directive are not generated as `WHERE` clauses for subqueries which match on the node for which these filters are defined.

Corresponding ZenDesk ticket [here](https://support.neo4j.com/s/case/500UN00000E4UykYAF/graphql-api-does-not-generate-correct-subquery-where-clauses-for-authorizationdirective)

Filters of `@authorization` directive are not generated as `WHERE` clauses for subqueries which match on the node for which these filters are defined.

Hey @darrellwarde, I see your point from a developer's perspective. However, the current state of neo4j-graphql is just not consistent. When executing the query of the example above I receive...

Filters of `@authorization` directive are not generated as `WHERE` clauses for subqueries which match on the node for which these filters are defined.

Hey @darrellwarde , any news on this? Was hoping that this will be addressed in v6, but according to the docs it was not?

Filters of `@authorization` directive are not generated as `WHERE` clauses for subqueries which match on the node for which these filters are defined.

Hey @darrellwarde, it is not about some kind of "default filter", it is about data being _secure_. Let me try to explain that in more detail: given the type definitions...

Add new filters for String types to enable case-insensitive filtering

Hey @darrellwarde, any plans on implementing this? Some time has been passed since my initial post and no one ever replied. The related ticket #4117 has been labelled with `small`,...

`@populatedBy` does not work in conjunction with `DateTime` data type: callback function is not called

Hi @MacondoExpress , thanks for the clarification. I can understand that `populatedBy` is intended for primitive fields only. However, from the API's consumer point of view, a `DateTime` is just...

`@populatedBy` does not work in conjunction with `DateTime` data type: callback function is not called

Thanks guys for solving this 👍🏻

Some `*Connection` types are generated with an erroneous aggregate type leading to aggregation count queries within connections to fail

Hi @angrykoala you are right, just using ````gql type MediaAssetClass @node { id: String } ```` leads to a correct schema generation. Seems that it only gets confusing when adding...

Some `*Connection` types are generated with an erroneous aggregate type leading to aggregation count queries within connections to fail

Sounds interesting! Additional hint: the connection type for `MediaAssetVersion` is messed up too: ````gql type MediaAssetVersionsConnection { edges: [MediaAssetVersionsRelationship!]! totalCount: Int! pageInfo: PageInfo! aggregate: MediaAssetMediaAssetVersionVersionsAggregateSelection! } ````

Thoughts and wishes for API v7

Hey @darrellwarde, any news on the workaround for CREATE,UPDATE,DELETE mutations to handle the :1 relationships via cypher? Are you still planning to release end of March/beginning of April?