Soft Delete

I think this feature would be also very nice to have.

But I think it should be possible today using @auth directive? You could just extend the permission query to also check the deletedAt field? I will try to stitch something together, brb.

Edit Here is a working example:


type Foo
    query: {
      and: [
          or: [
              rule: "query {queryFoo(filter: {not: {has: deletedAt}}) {deletedAt}}"
            { rule: "{$SHOW_SOFT_DELETED: {eq: \"true\"}}" }
          rule: "query($USERNAME: String!) { queryFoo {owner(filter: { username: {eq: $USERNAME }}) { username }}}"
  ) {
  owner: User!

  deletedAt: DateTime @search

  content: String!

queryFoo { content } will now return only Foos that don’t have a deletedAt Timestamp set.

SoftDeleting an object will now work using the updateFoo mutation and setting the timestamp. Regular delete would still work.

To allow also querying deleted objects, set VIEW_SOFT_DELTED to true in your JWT.
I must admit, that this of course very inconvenient and requires the client to either:

  • Always request two JWTs on login (one for normal operation, one for allowing to see soft-deleted nodes)
  • Request the tokens ad-hoc

Either way, the client would need to switch tokens to get the required functionality. So integrated soft-delete would be obviously the preferred way.

The more I think about it, the functionality you described (especially the requirement to bypass the filtering) is already implemented using update mutations for softDelete (setting the flag) and use filtered query to optionally filter out soft-deleted content or show them. Am I right?

Let’s continue this discussion here: