Radio button reset when switching asset models

[nicholasveronico]

Debug mode

• I have enabled debug mode
• I have read checked the Common Issues page

Describe the bug

When changing an asset's asset model, the radio button selection is reset. I am unsure if this is intentional; however, the values of other custom fields, such as the listbox, are not reset when changing an asset model. The following video shows the radio button selection being reset:

https://imgur.com/a/HB06QMj

Please note that the Billing custom field shown in the video is present in both asset models.

Thank you so much in advance!

Reproduction steps

1. Create a custom radiobutton field and add it to two fieldsets used in two different asset models.
2. Create an asset with one asset model and with the radio button field checked to one of the options and save the asset.
3. Edit the same asset but change the asset model to a secondary asset model.

The radio button will reset the selection.

Expected behavior

It is expected to keep the selected value of the radio button the same as long as the same field is present in both fieldsets associated with any two different asset models.

Screenshots

https://imgur.com/a/HB06QMj

Snipe-IT Version

v7.0.7 build 14172

Operating System

Ubuntu 20.04

Web Server

Nginx

PHP Version

8.3.8

Operating System

Mac

Browser

Safari, Microsoft Edge

Version

Edge: 126.0.2592.81, Safari: 17.5

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

Browser Console Error (happens before changing the asset model, though):
edit:925 
 Uncaught 
TypeError: $ is not a function
    at edit:925:5
(anonymous)	@	edit:925


When changing asset models, the following is logged in Snipe-IT's debug:

[17:34:02] LOG.warning: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /config/storage/framework/views/d2583f90a56f99c2c0bc40b509d051ff.php on line 35

I can confirm this issue also occurs on the demo instance. 

PHP Output:
https://hastebin.com/share/zevuhekayu.css

Additional context

This issue occurs on a fresh install and upgrade, on a manual install and Docker install. Data has not been manually edited in the DB.

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[snipe]

@marcusmoore can you peep this, or coordinate with @spencerrlongg or @Godmartinz to see who is best suited (and has the bandwidth) to dig deeper? I think this is related to the SC I created last week, so we might able to kill a few birds with one stone.

[marcusmoore]

I'll check it out 👍🏾

[nicholasveronico]

I'll check it out 👍🏾

Hi Marcus!

I just wanted to check in and see if there's any updates on this issue.

Thanks!!

[marcusmoore]

Still on my radar. I have done some work on this but it's not ready to be merged yet.

[nicholasveronico]

Still on my radar. I have done some work on this but it's not ready to be merged yet.

Awesome, thanks for the update!

[nicholasveronico]

Hi @marcusmoore!

Is there a PR or branch I can follow for this issue? I noticed a similar issue was fixed in #15486; however, this issue is still present.

Thank you so much!

[marcusmoore]

This got lost in the mix. I'll check this out this week.

[marcusmoore]

A couple notes: the behavior is different for when you're creating vs updating an asset.

Using a text field as an example: when you're creating an asset, selecting a asset model that has default values for a custom field will always set the value to the default, even if the user entered something different.

Continuing to use a text field as an example: when you're updating an asset, changing the value for an input, then switching to an asset model that has a default value for that input results in the user entered input 'sticking'.

In either case (creating vs updating), checkboxes and radio inputs are updated to the field's default value when the asset model is switched.

---

It seems like inputs that are "dirty", meaning a user has updated the value, should stick with what the user entered even if there is a default value for the field.

A question I have is, if a user hasn't entered input for a field, should the default value be applied? Does that change when creating vs updating 🤔

Any input @nicholasveronico?

[nicholasveronico]

A couple notes: the behavior is different for when you're creating vs updating an asset.

Using a text field as an example: when you're creating an asset, selecting a asset model that has default values for a custom field will always set the value to the default, even if the user entered something different.

Continuing to use a text field as an example: when you're updating an asset, changing the value for an input, then switching to an asset model that has a default value for that input results in the user entered input 'sticking'.

In either case (creating vs updating), checkboxes and radio inputs are updated to the field's default value when the asset model is switched.

It seems like inputs that are "dirty", meaning a user has updated the value, should stick with what the user entered even if there is a default value for the field.

A question I have is, if a user hasn't entered input for a field, should the default value be applied? Does that change when creating vs updating 🤔

Any input @nicholasveronico?

I think if the field has no value set initially, the default value being present is the most sound option. For radio and checkboxes, I do think the user's input should stick.

For creating vs. updating, in my opinion (assuming you mean switching asset models when creating an asset vs. editing), the behaviour should be the same (user input has higher precedence over default values). But, if there is no user-inputted value for that custom field, the default value can be applied.

[nicholasveronico]

Hi @marcusmoore! I was just wondering if there's any update on this issue? Thanks!

[snipe]

@marcusmoore Welcome back - can you take a look at this when you get a moment?