Re: [pve-devel] [PATCH manager] ui: lxc options: fix rendering default and '0' value for tty count

[Dominik Csapak <d.csapak@proxmox.com>]

On 11/17/25 11:41 AM, Thomas Lamprecht wrote:
> Am 17.11.25 um 10:21 schrieb Dominik Csapak:
>> if '0' was entered, the options grid would show an empty line. Fix that
>> by adding a renderer that checks if the value is a number.
> 
> I was a bit confused by this, as it sounded like setting it to '0' in the
> frontend caused some non-numeric value in the backend which then was handled
> wrong here.
> 
> But it's really just the default renderer in PendingObjectGrid's renderValue
> using a truthy fallback to empty string for the value, i.e. `value || ''`
> 
> Nowadays we could replace the boolean or `||` with a nullish coalescing
> operator `??`, which is limited to fallback only if the value is exactly
> one of `null` or `undefined`, that should also fix these issues in a more
> generic fashion.
> 

true, yeah i'll send a separate patch for that, then the first part
here shouldn't be necessary at all.

>>
>> If the default is set, the edit window would always pre-fill the value
>> '2' instead of leaving the field empty. Fix that by removing the
>> manually set 'value' property.
>>
>> Reported-by: Dietmar Maurer <dietmar@proxmox.com>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>   www/manager6/lxc/Options.js | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/www/manager6/lxc/Options.js b/www/manager6/lxc/Options.js
>> index 6cc2e2b4..0acb88f4 100644
>> --- a/www/manager6/lxc/Options.js
>> +++ b/www/manager6/lxc/Options.js
>> @@ -81,6 +81,7 @@ Ext.define('PVE.lxc.Options', {
>>               tty: {
>>                   header: gettext('TTY count'),
>>                   defaultValue: 2,
>> +                renderer: (value) => (Ext.isNumber(value) ? value : '2'),
> 
> But this would mask any other non-numeric value with "2" too, and then be
> potentially misleading. Initially thought this was more theoretic, but
> Ext.isNumeric basically comes down to `typeof value === "number"', so if
> anything in the perl backend just "looks" at the returned value the wrong
> way and it gets stringified along the way, we would mask the underlying
> value here.


caution there are two methods in extjs here:

isNumber (which i used and has the properties you described)

and

isNumeric, which actually tries to parse the value and checks if
it's a number (not NaN), so that would have worked out better
(but still unnecessary if the pending object grid is fixed)

> 
> In Yew based UIs being fully typed is OK as there deserialization fails
> explicitly and one has to chose the behavior for how one wants to handle
> this, but in JS we (sadly) cannot really relay on this.
> 
> 
>>                   editor: caps.vms['VM.Config.Options']
>>                       ? {
>>                             xtype: 'proxmoxWindowEdit',
>> @@ -90,7 +91,6 @@ Ext.define('PVE.lxc.Options', {
>>                                 name: 'tty',
>>                                 minValue: 0,
>>                                 maxValue: 6,
>> -                              value: 2,
>>                                 fieldLabel: gettext('TTY count'),
>>                                 emptyText: gettext('Default'),
>>                                 deleteEmpty: true,
> 


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel