Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)
On a form view the attribute `use_contacts` will:
- when set to True: enable us to add contacts which will be available on
any time in the calendar,
- when unset: the list of contact is only the contact currently beeing
seen directly in the calendar.
The feature for adding contact is thus not necessary when
`use_contacts` is unset. But it still appeared without having any effect
(which is unexpected).
This commit remove the contact adding feature when it has no necessity.
opw-715932
A recurring event with a start date and a time duration had a wrong start and
stop date computed.
Introduced at 76b724294a.
Previously the r_date contained only the start_date but now it contains both
start and stop dates. This implies that the method 'get_recurrent_ids' could
use 'get_search_fields' with a stop_date (depending on the domain order) and
returns incorrect dates.
This commit ensure to launch the get_search_fields with the start date.
Closes#15922
Add a 3 use cases with tests that were failing before.
datetime filters were not working correctly on stop filters
The `_get_recurrent_date_by_event` was only computing recurrency on the start
field of an event which can make a difference. A recurring event
start=2017-01-01 09:00:00; stop=2017-01-01 10:00:0
was not matched in a search ('stop', '>', '2017-01-01 09:30:00')
The filter != was not handled in the recurring use cases.
e.g. making the search 'start is set' in the web client is equal to
('start', '!=', False)
Searching with only a start filter matching recurring events but not the
first ("real") occurence, was returning no result if no stop filter was present.
start=2017-01-01 09:00:00; count=5
had no result in a search ('start', '>', '2017-01-02')
By default, an event can be modified by any employee. This is also the
case for private events, displayed as "Busy" to other users. However,
since any user can modify an event, nothing prevents him to change the
privacy setting in order to be able to see the content.
This commit introduces a global record rule which only allows the
followers of an event to modify it.
opw-705079
With the previous condition, the `final_date`
was not recomputed when the number of repetitions
(count) was changed alone, without changing `recurrency`
(nor with other fields, such as start/stop date)
This revision makes sure to recompute the `final_date` when
there is a change in the number of repetitions without
changing the `recurrency` fields, when the event is recurrency
and the end type is `count`
opw-703812
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
When adding a partner "filter" to the calendar view, it only works if we
select directly the partner and not when we choose him via "search more"
or create him on the fly.
This commit uses the partner id directly which is available in the field
value in those three possible instances.
opw-702491
Odoo Translation Bot