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)
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')
Before this commit there was an error when we chose a monthly recurrence
with "Day of Month" of type "Day of" because the code expect them to be
set. In any case they are required field so if they are not field we
should just ignore it.
opw-702852
Function has been prefixed with an underscore by commit #21e4579551a
Avoid traceback where 'get_recurrent_date_by_event' is not defined
Thix commit closes#13727
For historical reasons, `vobject`* Python library is not mandatory in
Odoo.
Since refactoring 6af6148a24,
get_ics_file() returns now a dictionary whose keys are calendar.event
ids and values are the corresponding ics file.
If `vobject` is not available, it returns an empty dictionary that
could cause calendar.py to crash because it always expects to find the
event's key.
Before this refactoring, this method was called and architectured in a
different manner, so no crash was happening.
This commit prevents the crash if `vobject` is not installed and logs a
warning.
*vobject allows to generate iCalendar files
If the method "_get_display_time" is called on an event and if the
user or partner has no timezone set. The string returned by the function
contains the value 'False' instead of a timezone.
To fix this, we replaced the "False" value by "UTC", because UTC is the
default timezone in Odoo.
The API of `Registry` has been modified as follows:
- `Registry(name)` returns the registry of the given database
- `Registry.new(name)` forces the creation of a new `Registry` object
- `Registry.delete(name)` discards the given registry
- `Registry.delete_all()` discards all registries
- `registry.setup_signaling()` initializes the signaling for `registry`
- `registry.check_signaling()` returns an up-to-date `registry`
- `registry.signal_registry_change()` notifies that `registry` has changed
- `registry.signal_caches_change()` notifies potential cache invalidation
The onchange produced a traceback because, even if start and stop
are required, they have no default value. Adapted `_get_duration`
function so that it is robust to that usecase.
Change `send_email_to_attendees` signature to force setting email
template and remove `email_from`, since it is not usefull.
Now, when sending email to attendee, meeting author will also received
an invitation.
`get_ics_file` has been modified to be executed in batch.
- `start` and `stop` fields are not computed anymore. Indeed, it was not normal
to have required stored computed field. Normally we shouldn't write on these
fields, but since client calendar api need them, we keep them as normal
datetime fields
- `start_date` and `stop_date` become stored computed date fields depending of
`start`,`stop` and `allday`. An inverse method allow to write on these fields,
since it can be the case from the form view
- `start_datetime` and `stop_datetime` follow the same logic
- `onchange_allday` code is mostly moved in `_inverse_dates` of new computed fields
- `_set_date` method (called in create/write) is now removed, since it does the same
thing as old onchanges
- `_onchange_duration` is kept to adapt `stop_datetime` when changing `start_datetime`
or `duration` on form view
- Duration is now 'zero' in database for allday meeting. Before, it was not changed.
Setting it to zero is less falsy. `duration` can not (yet) be a computed field since
it depends on others computed fields.
After migration, we manage to keep old behavior but the code was crap. Switching stored computed
fields make it cleaner, and respecting new API standarts.
This changes avoid multiple methods doing almost the same thing, and is less 'buggy'.
- move `get_ics_file` from calendar.attendee to calendar.event
- remove calendar.event arguments to convert method into
`api.multi`, which make more sense
- `create_attendees` now returns recordset instead of list of ids
- change signature of `get_interval` method
Migration of all python code, mostly withtout chagnes. And adapting
xml files to guidelines.
On calendar.py, some changes have been perform to make the migration works :
- `_compute` method has been split into `_compute_dates`, `_compute_attendee` and `_compute_display_time`.
- remove unused method `onchange_partner_ids`, `check_partners_email`
- make `compute_rule_string` use a cache record instead of a value
dict to avoid crashes
- remove `new_invitation_token` method, and make it a default value on attendee creation
- add a default value on `day` field, otherwise the "Please select a
proper day of the month" exception is raised during the onchange
Christophe Matthieu