[15.0][FIX] fieldservice: Fixed expected singleton on mass edit

[BernatObrador]

Prevent "Expected Singleton" error when applying mass edit actions on FSM Orders.

Issue:
Mass editing multiple FSM Orders was causing a ValueError: Expected singleton due to the incorrect use of self in write, where self was assumed to be a singleton but was actually a recordset.

cc https://github.com/APSL HT02030

@miquelalzanillas @lbarry-apsl @mpascuall @peluko00 @javierobcn @ppyczko please review

[OCA-git-bot]

Hi @max3903, @wolfhall,
some modules you are maintaining are being modified, check this out!

[peluko00]

LGTM!

[lbarry-apsl]

Code reviwed LGTM

[mpascuall]

LGTM!

[dreispt]

get(x, False) is redundant, as the default result for a missing key is already a falsy value.
Does this if need to be inside the loop? It doesn't make any use of the iterated record.

[BernatObrador]

Hi,

I do not change the write logic, just solved an error when you try to mass update records that was throwing an expected singleton error.

I just added for record in self, and change the self._calc_scheduled_dates(vals) for record._calc_scheduled_dates(vals) to avoid that.

If you want, I can do this too, but it wasn't the main goal.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[ivantodorovich]

Hello @BernatObrador .

I think this will not work correctly.

The issue you're trying to solve is that _calc_scheduled_dates is sometimes reading a record field (e.g.: self.scheduled_duration), and of course that doesn't work when self is a recordset.

However, _calc_scheduled_dates is modifying the vals dictionary. Meaning each record could potentially have a different dictionary.

IMO the solution is to get rid of _calc_scheduled_dates, and solve with computed fields and/or inverses.

Maybe even some onchanges.

I see 3 things that this method is doing:

• Computing the scheduled_duration when both scheduled_date_start and scheduled_date_end are set --> solution: make scheduled_duration computed
• Modifying the scheduled_date_start when only scheduled_date_end is changed, to respect the duration (shift the interval) --> IMO this behavior can be dropped, as we don't see this thing in other modules like the core calendar for example, it doesn't make sense from a UX point of view IMO
• Modifying the scheduled_date_end when scheduled_duration is modified and scheduled_date_start is set, to respect the duration (shift the interval) --> IMO this behavior can be dropped, as we don't see this thing in other modules like the core calendar for example, it doesn't make sense from a UX point of view IMO

For the last two, besides dropping this behavior, I would suggest switching the form widget to use daterange, and so align the UX to other Odoo core modules