[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

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[BernatObrador]

@ivantodorovich Could you please review the latest changes?

I’ve moved the logic from _calc_scheduled_dates into separate onchange methods, and I also updated the view to use the date range widget as you suggested.

Thanks!