Previously, the calendar view only shown a 1h item whatever the duration of the
maintenance, which was wrong every time the maintenance took more or less than
exactly one hour.
Adding this parameter allows showing a calendar view reflecting the real time
taken by the maintenance operation.
Closes#18072
The maintenance.request "active" field was renamed to "archive" for some
strange reason by commit 9a20c6556f.
The value was also inverted.
Unfortunately, "active" was not replaced in a search filter.
opw-744168
When we set a period for preventive maintenance on an equipment which
has no maintenance team set, the cron cannot create the maintenance
requests.
To fix this issue, the maintenance team is now required when a period is
set on an equipment.
When you define recurring maintenance requests on an equipment, the
maintenance duration and the maintenance team is not set on the created
requests.
The problem comes from the creation method called by the cron that
doesn't use the duration and maintenance team to create new requests.
We now use these fields in the request creation
The xml file with the cron that creates the recurrent
preventive requests was not loaded in the system, so we needed to add
it.
Before, the cron was foreseen to only create the maintenance request on
the day that the request was foreseen (in the morning). Now, it will
create a request if none exists on the next_action_date. That way the
requests can be planned for.
The other problem is that the '_compute_next_maintenance' method
for calculating the next_action_date does not take into account
the possibly manually already created requests. So, now, the next
maintenance is calculated with the closed requests and the open ones.
If the first new one is in the past, it takes that date in the past. If it is in
the future, it will see if the gap is big enough to put a maintenance
in between the last done maintenance (or now) and the first new one.
If none exists, it is today + period.
That's why we have to add the 'request_date' in the depends. And take
into account the preventive requests existing on an equipment.
It used to be based on owners, but owners are automatically
followers. Restricting on followers makes the visibility
of equipments and requests consistent with the mail notifications
linked to them.
Avoids issues with "phantom notifications" that appear in the
inbox counter but aren't visible.
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
Martin Trigaux