Tagify sporadically uses tag-text for tag-value

[mebeingken]

Wappler Version : 6.8.0
Operating System :
Server Model: node
Database Type:
Hosting Type:

Expected behavior

Tagify should always evaluate to the tag-value field when used in a form repeat

Actual behavior

Sometimes, not always, the tag-text value is sent in the form post.

How to reproduce

I cannot produce a consistently reliable use case of this, but here is what I am seeing.

Given this form repeat with a tagify component within:

<div is="dmx-form-repeat" id="component_recipe_list" dmx-bind:items="recipe_edit.data.recipe_components.count()?recipe_edit.data.recipe_components.groupBy(`recipe_id`).keys():0" sortable="true" handle=".draggable_step_handle" animation="400">
...
	<input class="form-control component_recipe" is="dmx-tagify" id="inp_component_recipe_id" name="child_recipe_id" mode="select" nocustom="true" min-chars="0" max-items="999" dmx-bind:data="get_all_planner_recipes.data.recipes" tag-text="title" tag-value="recipe_id" tag-image="primary_image" required="" dmx-bind:value="$value&gt;0?$value:null">
...
</div>

Most of the time, this works. The proper id is sent.

However sometimes, with the exact same data in the entire post, and the exact same selected value, the tag-text is sent:

I should note that the ternaries used in this are part of the troubleshooting...they were not used originally.

The only hint of a possibility is that I have so far only been able to make it fail when the tag-text begins with a numeric character. But even this does not ALWAYS fail.

[mebeingken]

Bump...

[bpj]

Bump - this is happening for me to

I'm wondering if it is for items that go beyond the max-items position when using 'Select' mode

[mebeingken]

Ya, this never got picked up so I had to switch to a standard select element.

My previous hypothesis about numeric characters fell apart, your theory seems more sound.

[bpj]

It appears to see it as a non-listed item so therefore uses the text entered as the value. The only reason I can think of is that it is only looking in a certain number of items

[patrick]

Does this only happen inside a form-repeat or also outside of it?

[patrick]

@bpj

I'm wondering if it is for items that go beyond the max-items position when using 'Select' mode

The max-items only limits the number of items that is shown in the autocomplete droplist.

I'm trying to reproduce the issue but currently have no success with that. If there is more information when it fails then perhaps I could pinpoint the problem, currently I have no idea where to search.

[mebeingken]

I had to pull these out of the app and go with a standard select so the problem went away.

I just now tried to recreate in a test page and can no longer see the issue.

[kfawcett]

@patrick This is happening to me as well. It appears to happen when there is a space at the beginning or end of the value for the tag-text runtime element.

@bpj and @mebeingken, could you see if that is the cause for you?

As an example, the First Name has a space at the end. If I remove it, then the form submits successfully. If I add it back it gets the error. I've validated with multiple records and this happened consistently.

[guptast]

I am experiencing the same issue. The tag-text string is swapped with tag-value and as a result, it fetches the incorrect record.

I updated the code from dmx-autocomplete to dmx-tagify due to issues with the update event being triggered twice.

I have added a screenshot and tagify code below.

@patrick

Does this only happen inside a form-repeat or also outside of it?

In this project, the tagify (and previously autocomplete) component is inside the form-repeat.

<div class="col-1">
    <div class="input-group">
        <input type="text" is="dmx-tagify" class="form-control form-control-sm" id="inp_product_id" name="product_id" aria-describedby="inp_product_id_help" placeholder="Product *" required="" dmx-bind:data="sc_workorder_form_products.data.q_list_products" tag-text="product_code.toString()" tag-value="product_id" data-msg-required="Required" dmx-bind:value="product_id!=null?product_id:''" dmx-on:updated="run({condition:{outputType:'boolean',if:`value!=\'\'||value!=0`,then:{steps:{run:{outputType:'text',action:`sc_workorder_form_product_selected.load({selected_product_id: value})`}}}}})" mode="select" nocustom="true" max-tags="1">
    </div>
</div>

[patrick]

Can you test with the following update if it still happens.

dmxTagify.zip (10.1 KB)

[guptast]

Hi Patrick,

Sorry, the updated code didn't fix the issue. I have included a short video below to show what happens when I type the product code 96560 and press enter to select it. It changes to Product Code 33027, which is actually product_id of the product code that I had originally typed.

[patrick]

Here a new update: dmxTagify.zip (10.1 KB)

[guptast]

Hi Patrick,

Thanks for the updated code. This has resolved the issue partially.

When selecting the product codes originally, the product id values are correct. I have included a screenshot with two sets of original product codes - Code 96560 & 74938

When I edit the same workorder, the values get swapped with product id of the original product code. Please note Code in the 1st line has changed to 33027 and Code in the 3rd line has changed to 12065. However, the Product Descriptions have remained for the original codes.

Upon checking the dev console, I can see only two server connect API calls to workorder_form_product_selected, instead of making/repeating 4 calls for each line record.

[patrick]

So if I understand correctly, it now only still has an issue with the initial value.

Can you check if the following update fixes it.

dmxTagify.zip (10.8 KB)

[guptast]

Hi Patrick,

I have just tested the latest code, and everything is now working correctly at all stages - both during the initial code selection and when editing an existing record.

Thank you for resolving this bug so promptly, I really appreciate it.

[Teodor]

Fixed in Wappler 7.6.1