Còdec

I’m closing thins thread after two months without response. If you want to reopen it, please, feel free to open a new thread in this forum. Many thanks.

That’s interesting! This error indicates that you are trying to establish a SSL encrypted connection over HTTP (https://) to a host that does not have a valid SSL certificate, or maybe a self signed certificate, it could be?

You have two approaches to solve this issue. If the host does not have a certificate, update your backend base URL to work with the http:// schema instead the https://. If the host has a self signed certificate, you have to skip SSL verification. To do that you can copy this code in your WordPress theme functions.php file, or maybe with a plugin like WPCode:

add_filter( 'http_request_args', 'bazed_skip_nc_ssl_verification', 10, 2 );

function bazed_skip_nc_ssl_verification( $args, $url ) {
    if ( false !== strpos( $url, 'https://xxxBASEURLxxx' ) ) {
        // Skip SSL verification for NC HTTP requests.
        $args['sslverify'] = false;
    }

    return $args;
}

Pleas, if you have to copy this code on your theme, do it with care, I don’t want to break nothing on your WordPress site!

Hi @bazed,

I can’t see the attached image, sorry, but we can understand something from your explanation.

Let’s see if this help: The CLIENT ID field of the credential should be the username with which you want to authenticate against Nextcloud, the CLIENT SECRET its password. Based on your last message, you are using Bridge as the client_id/username. Does this username exists on your Nextcloud? The Sabre\Dav\Exception\NotFound exception could be explained if no user with this username were found. Maybe you are introducing the username in the NAME field of the credential? This field is an internal label to identify the credential, but it is not used in the authorization request.

Hey, @abadu, we mark the thread as resolved if no further questions. Many thanks!

Hi @abadu!

Many thanks for your detailed message, this make our work much more easy.

As an answer to your question, there is no hard coded logic to serialize the bridge payload. This logic is driven by the bridge custom fields and mappers. Using this two features you can control how forms bridge will serialize the payload.

First of all, one question: Did you set up the bridge manually or with the template wizard? If you did the former, the resulting bridge setup should looks like as follow:

## Custom fields

• attribs.locale: $locale
• preconfirm_subscriptions: 1 (or 0 if you’re using the Opt-In template)
• status: enabled (or disabled if you’ve changed the default value)
• lists[0]: <listId>
• …
• lists[n]: <listId> (Being n the number the lists you’ve selected in the wizard)

## Mappers

• your-email: email | string
• your-name: name | string
• preconfirm_subscriptions: preconfirm_subscriptions | boolean
• lists[0]: lists[0] | integer
• …
• lists[n]: lists[n] | integer (Being n the number the lists you’ve selected in the wizard)

## Payload

{
  "attribs": {
    "locale": "string"
  },
  "precomfirm_subscription": "string",
  "status": "string",
  "lists": "integer[]",
  "email": "string",
  "name": "string"
}

Based on your explanation, I proposed two hipotesis:

1. Your bridge has a bad definition for the lists custom field. Maybe something like:
   – lists: [5]
2. Your bridge has a mapper that casts lists payload attribute as JSON. Something like
   – lists: lists | JSON

To solve the first hipotesis, you have to use JSON fingers on the custom field definition to write them to the payload as an array: lists[0], lists[1], and so on.

If you have a mapper with a json mutation, remove it from the bridge mappers.

## Extras

1. With the attribs field of the payload you can pass custom fields to your subscription requests. By default, Forms Bridge proposes to store the language code (locale), but you can add more at will, whether they come from the form responses or from the bridge custom fields.
2. You can add an ignore mapper to remove non standard fields from the payload, like your cf-turnstile-response. To do this, open the bridge mappers panel, click on add and set up something like this:
   – cf-turnstile-response: cf-turnstile-response | Ignore

Let us know if you can resolve your errors!

Hi Dan,

First of all, the plugin is in development, get it as a beta! We’ve released it to test it on real situations like this, so you are very welcome.

Second, we’ve released a patch to the version 3.3 of Forms Bridge with the fix of the bug your are reporting, included the typo, many thanks 🤗. Try to update the plugin to the version 3.3.1 and try again. If we don’t have more feedback, we will assume the issue is fixed, otherwise, please, reopen this thread.

On the other hand, the Odoo JSON-RPC API its complicated: Odoo is modular and models are extended based on the active modules. This is not well resolved by Forms Bread, we know it. We’ve made tests with Odoo 18 and the CRM and Invoicing modules activated and it works fine, but with other configurations some bridges may fail. We are working on a page with documentation to explain it!