[1.9? - 1.10] Tokens not working in Dynamic Forms

[LivyChops]

Create a ContentType with a text field - with either a token as a default value or by setting the property value and binding to a Dynamic Form element within a layout never evaluates, in either case.
e.g. {User.Name} or #{User.Name} results in just the token text itself, not even empty.

My use case is a simple Contact Form binded to a ContactForm Type containing only 4 fields [which now binds correctly thanks to Sipke], one being a Hidden Field with a Value of 'any-token-you-select' results in the aforementioned.

Possibly related:
#5576
#5407
#6497 - jtkech's comment about tokenization
#6237

[dyrgutt]

I concur:

"Dev" works partially - partially, as in - if a user constructs a form in a page, the above results; however, if they create a Form directly it works.
"1.10" doesn't work at all.

Performed Tests on: [Dev]

1. Bare setup
   Enabled Dynamic Forms
   Created a New 'Form' with 3 Fields [email / text / hidden=token {User.Name}]
   Enabled Storage
   Works.
2. Create a CustomForm Content Type [3 fields]
   Edit Form, leave initial settings but enable Create Content [content type CustomForm], enable publish.
   Associate bindings
   Doesn’t Work [All fields Empty].
   However, apply 3690968 fix, [var bindingSettings = element.Data.GetModel();]
   Works.
3. Create new content 'Page'
   Add form to default layout's [column12] and configure:
   [default] + enable Create Content, ContactForm, publish.
   Add [3 fields / submit] - do bindings. Publish/Test
   Does not work [Token field empty]

"1.10" Fails all 3 tests above.

[jtkech]

There are many issues around tokens but it's more because there are many ways to use them. There are open PRs and some are already fixed but in a different branch...

Here, it seems that we talk about tokens used for the initial values of form fields, not those used to grab user inputs. Then, a dynamic hidden field can be used when creating a content on submission.

If so, indeed, as @dyrgutt, tests 1. and 2. pass in dev, but test 3. also pass for me. Of course, if i apply 3690968 that fix the binding issue, but right now only aplied to 1.10.

In 1.10, i can repro the issue described by @LivyChops where the token text itself is used. Here, i think it's because of 41e9052 that allows the initial value of some fields to be tokenized, but not applied to 1.10.

Best

[dyrgutt]

@jtkech nailed it, mate - 41e9052 certainly sorts it. Funny about that third test - when I get some time - i'll perform it again on the latest merge; just to be sure. Though if @LivyChops replies otherwise, I think this can be closed ;)

[jtkech]

@dyrgutt thanks for having tested and confirmed this.

[sebastienros]

@jtkech Could you summarize what's left to be done once your PR is merged?

[LivyChops]

@jtkech @dyrgutt using the latest dev, 41e9052 does indeed fix the issue. I can also confirm @dyrgutt that your 3rd test does work, too :)

[sebastienros]

Can I close it?

[jtkech]

@sebastienros

3690968 is now in dev because of a recent merge of 1.10, and 41e9052 is still only in dev. So here we would need to apply 41e9052 to 1.10.

About my PR, if you reference #6535, it is related to content type field default values. In this PR it's about dynamic form element default values.

So, you can close it but 41e9052 is not applied to 1.10.

Best

[LivyChops]

Sorry @jtkech , didn't see your post - yes once @jtkech advice is followed - you can close it 👍

[jtkech]

@LivyChops no worries

[jtkech]

@sebastienros

So, what about 41e9052, do we need to do a PR that target 1.10 or 1.9.x?
Or can we let it like this, because it will be part of 1.10.1?

Best

[jtkech]

@sebastienros

Just seen a committee video where you said that this issue is fixed because 41e9052 is in 1.10. But this is not the case, only in dev.

Best.