[Bug] Form confirmations settings are incorrect in GraphQL

[dam6pl]

Describe the bug

When I add a new form and add a new confirmation to the form, the confirmation is enabled by default, but not in GraphQL.

To Reproduce

1. Add a new form.
2. Add new confirmation for the form.
3. Back to the Confirmations table, where added confirmation is enabled.
4. Run following GraphQL query:

query MyQuery {
  gfForm(id: "x", idType: DATABASE_ID) {
    confirmations {
      isActive
    }
  }
}

which returns:

{
  "data": {
    "gfForm": {
      "confirmations": [
        {
          "isActive": true
        },
        {
          "isActive": false
        }
      ]
    }
  },
  "extensions": {
    "debug": []
  }
}

Expected behaviour

By default, newly added confirmations should be enabled in GraphQL.

Additional context

n/a

Technical Info

• WordPress version: 5.9.3
• WPGraphQL version: 1.8.1
• Gravity Forms version: 2.6.1
• WPGraphQL for Gravity Forms version: 0.11.0
• Other relevant frameworks/plugins: n/a

[dam6pl]

@justlevine do you know when it will be resolved?

[justlevine]

@dam6pl tbh I'm not sure, I'm hoping to have the time to tackle v0.11.1 in the next few weeks, but you know what they say about release dates in OSS projects ;-)

If you want to change it on your own install in the interim, the source of the issue is the empty() check here. We're also always open to PRs 😎

[dam6pl]

@justlevine ahh, okay. I'll prepare the PR soon, as temporary I fixed it with the filter :)

[KoduVaal]

why do we need conditional logic to be queried? all the form submission happened in the back-end and providing result. so shouldn't that confirmations should have only valid confirmations?

[justlevine]

Hey @KoduVaal
confirmations are a list of all the possible confirmations registered to the form. It's not a question as to whether it's "valid", but rather so your frontend knows what to do (e,g display a message, redirect, etc... as determined by conditionalLogic ) when submitGfForm() comes back successful.

[KoduVaal]

@justlevine ,
I'm talking about confirmations after form submission. Conditional logic will be processed in the backend anyway, so why do we need to double process? writing same function in the frontend?

We are not following what gravity form doing it with REST API. Confirmation will be only one. if we specifically need to modify result with confirmation, it will be available with the form details.

[justlevine]

We're not double processing, and I dont see how we're going against the GF REST API.

Let me try to explain again:

Form Confirmations have their own set of conditional logic rules. These logic rules are used to determine which confirmation to display. For example, you could have one confirmation for logged-in users that redirects them to a different page, a different confirmation for users who selected a certain checkbox, another for those who filled out a text input with a value KoduVaal, and a default 'Thank for your your submission' confirmation for any valid submissions that to match any of the above conditions.

submitGfForm(), its REST API parallel, and the underlying GFAPI::submit_form() only return the entry object on success, not which confirmation to show the user. In GF native, thats either handled as a server redirect or an ajax script. In headless (rest or wpgraphql) we need to check the entry against the confirmation logic to determine what the app should do.

If this is still not clear, i'm happy to discuss this further, but please open a new topic in Discussions so we don't spam this issue.

[KoduVaal]

@justlevine continued on #255