Univention Bugzilla – Bug 31510
MultiInput caches too much
Last modified: 2013-06-13 14:37:00 CEST
Seen in Ticket #2013042621001326 When adding another row to a widget that supports multiple values the umcpCommands are cached for 100ms. This is used especially in UDM. There are problems with complex widgets in MultiWidget. For example computers/ipmanagedclient: DHCP service DHCP service IP address MAC address MAC address depends on MAC address (network). It is possible that the parameters used while "Searching all DHCP services)" are also used for "Getting all MAC addresses", even when MAC addresses were not set at the very moment DHCP services were queried. Thus, MAC addresses will be empty. As soon as the user changes a MAC address, everything is fine because now the cache was invalidated (100ms).
I suggest the following patch. After being applied I was not able to reproduce the behaviour. It should also be tested if the cache still works (and is only reevaluated when necessary). MultiInput.js _createHandler: function(ifunc) { var _valueOrDeferred = null; var _lastCall = 0; + var _lastOptions = undefined; return function(iname, options) { var currentTime = (new Date()).getTime(); var elapsedTime = Math.abs(currentTime - _lastCall); + var optionsChanged = !tools.isEqual(options, _lastOptions); _lastCall = currentTime; + _lastOptions = options; - if (elapsedTime > 100 || !(lang.getObject('then', false, _valueOrDeferred) && lang.getObject('cancel', false, _valueOrDeferred))) { + if (elapsedTime > 100 || !(lang.getObject('then', false, _valueOrDeferred) && lang.getObject('cancel', false, _valueOrDeferred)) || optionsChanged) { _valueOrDeferred = ifunc(options); } return _valueOrDeferred; }; },
Alexander, would you mind looking at the problem/solution? I guess this won't break anything. Worst case is that form loading is slower.
(In reply to comment #2) > Alexander, would you mind looking at the problem/solution? I guess this won't > break anything. Worst case is that form loading is slower. The described problematic behaviour looks correct to me. I went through the patch and investigated it on a test system. AFAIS it looks to me as a nice workaround for the described problem. The parameter "options" contains the current list of mac addresses (i.e., the values of all its dependencies) such that a fast second call will not yield the cached value as the list of mac addresses differs (1st time empty list during initialization, 2nd time with set values).
The patch has been applied. I couldn't find any side effects. - ucs3.1-1 & YAML: univention-management-console-frontend (2.0.244-10) - ucs3.1-2 & chanagelog: univention-management-console-frontend (2.0.256-1)
reported by another customer
Reported again: 2013060721001304
UCS 3.2 changes → OK changelog → OK UCS 3.1-1 Errata changes → OK YAML file → OK test → OK
http://errata.univention.de/ucs/3.1/123.html