This commit places a tip to indicate the user to scroll when the anchor
is out of viewport.
Also now allow to wait that the user types on his keyboard before
consuming a step when text modification is required on a contenteditable
element.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
closesodoo/odoo#48678
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit adds some untracked modifications rules that ignore
these DOM modifications:
- Ignore when the class "o_tooltip_parent" is added or removed (will
be important with the next commit)
- Ignore when the ID of an element changes (normally never in Odoo
codebase (at least not alongside other changes), but jQuery uses
ID modification for some performance improvements).
This is required to avoid loops in the update system (the
o_tooltip_parent class is added, thus we update tips, which search the
DOM so jQuery changes IDs, thus we update tips, which ...). Previously,
this already occured but less frequently than it is about to be
with future tips improvements.
To be able to do that change, the system had to be reviewed. Indeed,
the DOM mutation observer was debounced thus leading to considering a
very small portion of DOM mutation. As we now have to check the addition
or removal of a specific class or ID, we have to consider them all. In
fact, it worked by chance before... this occured:
1) The user clicks on something, the UI is updated -> DOM mutation
2) The code uses jQuery so a strange ID update is done -> DOM mutation
3) As the observer is debounced, we only see (2), which was not an
ignored DOM mutation -> we update the tips.
Now that (2) is an ignored DOM mutation, if we still debounce, (3) will
not update the tips while it should have because of (1). In fact, this
could theoratically break already: if (2) is a tip update for some
reason, (1) will be forgotten in the current codebase.
Instead of debouncing we now register all DOM mutations and process
them in a debounced way. So if I receive 3949 mutations over half a
second, I will save them all but only start processing them once I am
not receiving some anymore. And most of the time, only a couple of
processing is needed to know that a tracked DOM mutation occured, which
thus needs to lead to a tip update.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
This commit adds the case where the overflow of an anchor ancestor is
'hidden auto' and not only 'hidden'.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
A system was implemented to not close/open a tip if the user
leaves/enters the anchor and immediatly re-enters/re-leaves it but that
system was broken at some point.
This commit restores it.
Part of https://github.com/odoo/odoo/pull/48678
task-2228694
In compute method _compute_expected_date() all PO lines
are processed to get expected date, but in note and section
line we dont have date_planned, it generates error. filtered
the PO line to process if only they are not having display_type.
Fixes-2234053
closesodoo/odoo#49433
X-original-commit: 2163c6a05476ddfbf899e46eac565b7f5cc5f46e
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce:
- install timesheet
- go to general settings > set documents layout to use 'external_layout_boxed'
- go to timesheets > list view > select all > print > timesheet entries
Previous behavior:
the first line of the report's table is missing a border
Current behavior:
borders are consistent
opw-2230710
closesodoo/odoo#49432
X-original-commit: a70437c0fc8127976ce00b5ec1ef4ae006b28e15
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
odoo/odoo#46024 improved the serialisation of arrays being logged (in
order to get more relevant data than just `Array(5)`.
However, chrome apparently serialises *argument* objects as array-like
with a few nits, namely that arguments have non-numeric properties
which don't necessarily have a value associated with them.
The array formatter / converter assumed all properties had a value,
resulting in the process crashing rather dramatically.
Filter out non-numeric properties on arrays.
closesodoo/odoo#49418
X-original-commit: 5ff1e41c98f042fd13a1762977cc76604231dfd4
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
1. Install PoS and Accounting
2. In a product category activate the Inventory Valuation automated
3. Sell a quantity 0 of such product via POS
Traceback will occur when confirming the sale because the inventory
valuation do not handle zero quantity
opw-2206625
closesodoo/odoo#49417
X-original-commit: d501ddd1e80bc4e3ff90cd9b34eb43c27e55ff97
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The generation of SN is incorrect with the following initial sequence:
`BAV023B00001S00001`.
Indeed, the sequence generated is: `BAV023B00001S`, `BAV023B00002S`.
This occurs because the same digits `00001` appear more than once.
opw-2230913
closesodoo/odoo#49408
X-original-commit: b3369bc230160d6cafec77eed0e756c6f1c576d9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, check availability button was becoming
hidden, even if move is partially available on MO.
Fixed it.
Fixes-2234494
closesodoo/odoo#49381
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Currently, when we add many2many field relation with purchase.order in view
where view does not have state field, it throws error, it is because
purchase.order list view has attrs for column_invisible which parent.state
which is wrong, purchase.order will not have parent.
With this commit, remove wrongly added column_invisible attrs on invoice_status
field.
task-2195175
closesodoo/odoo#49416
X-original-commit: 79a738fb7fa852c4e2e9fc127fa63dbc4ffd4a53
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1. Install PoS and Accounting
2. In the PoS setting activate the Invoicing option
3. Sell an item X with Invoice toggle to client Y and pay it
4. Sell the same item X with Invoice toggle to the same client Y with
quantity -1
5. Close the PoS session
Traceback wil occur when trying to Validate Closing & Post Entries
because in '_create_invoice_receivable_lines' already reconciled lines
are already filtered out so invoice_receivable_lines is empty
opw-2206625
closesodoo/odoo#49407
X-original-commit: e9f5e2b7fdd332ca0fc0f43c839118ef82d4eddb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If for some reason someone wanted to develop a textarea using the
editor which is supposed to work as a public user (like we are trying
to do on Odoo.com), it was not possible. The code was "designed" to
allow it but there was one problem: the lazy loading of the editor
assets required a `render_template` call to the server... which cannot
be done from a public user.
This commit solves the issues by allowing the lazy loading of assets
to use a custom route if required. That route is then used by the editor
"root". That route performs the render_template as a superuser provided
that the view's xmlid is whitelisted.
Note: there was another unauthorized call for public user: the
colorpicker. This was solved by disabling the colorpicker template rpc
for public user, they will still get the default summernote one.
Part of https://github.com/odoo/odoo/pull/48981closesodoo/odoo#48981closesodoo/odoo#49398
X-original-commit: e84a0bfdc99c21406861b88c02b11c925d92f927
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The caching system which was implemented was not working if the
same asset was asked twice "at the same time" = "if the second demand
occured while the first demand's RPC loading was taking place".
Part of https://github.com/odoo/odoo/pull/48981
X-original-commit: ba0ac348a3700331cec6955625ca2b6c72600ced
Before this commit, we had an error when writing on account_opening_move_id, fiscalyear_last_day, fiscalyear_last_month on multiple company at once
closesodoo/odoo#49397
X-original-commit: 46c7b398b678da7a977e466e626162d66e1ee05f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
There was 2 problems that caused the Publisher tour to fail:
1. The pointer on the main menu was pointing to a link
containg "New Course" as text instead of "Course".
2. After selecting a picture (by clicking on it), the picture is
automatically added and so no need to click on add button; had to
remove this extra step.
Task ID 2228922
closesodoo/odoo#49390
X-original-commit: b2f2c5e4ecfd6bf39ce0b2b724827202629231f1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Go to Inventory > Configuration > Operation Types
- In Receipt, activate 'Show Detailed Operations'
- Go Inventory > Overview, click on 'Receipts'
- Create a picking, and in the 'Operations' tab add 5 units of a product
tracked by unique S/N
- Click on the + sign
- Set the First SN (e.g. TEST001) and Number of SN to 5, then Assign
Serial Numbers
Nothing appear in the Detailed Operations, and it's impossible to
validate the picking.
The stock move lines are created, but not linked with the picking.
opw-2230913
closesodoo/odoo#49383
X-original-commit: 55ffc3027d26a36fc390d5efefa2d743cdc3e09f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P with a Sales Price of 5000 and a Cost of 3000.
- Create a bill for 10 units @ 3000, post
- Create an invoice for 10 units @ 5000, post
- Create a customer credit note for 5 units
- Open the Product Margin report
The # Purchased is 15 while the # Invoiced in Sale is 10.
The query incorrectly sums the invoice lines based on their type. We
should group customer invoices with customer refunds, and group vendor
bills with vendor refunds. When grouping we should subtract invoices
and refunds.
Note that the `avg_unit_price` is not modified since there is no reason
to refund a product at a different unit price.
opw-2211636
closesodoo/odoo#49349
X-original-commit: d3c6b16e2ad2166b636372b537292e06d4d575c4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The 'Configure Variant' button doesn't show any relevant information in
case of a product variant. It is only useful for a product template.
opw-2229881
closesodoo/odoo#49059
X-original-commit: d57331f5403159692591fe75c6e8e4f1e9ac6b02
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fix regression introduced with e0ed7b12ca
Issue without current commit:
When doing `abort` next updates from the bus are only received after the normal
timeout, which makes the interface unresponsive to updates during that amount of
time.
`abort` is for example called during `addChannel`, where it is specifically
documented that new updates are to be received immediately.
closesodoo/odoo#49355
X-original-commit: 888610e5e07794e000ef27edcb075cb45c1e2ccc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Create a new survey 'Test Survey';
- Add a section 'S1';
- Add a multiple lines text box question 'Q1';
- Add a section 'S2';
- Add a section 'S3';
- Don't move any of the section or question to avoid changing the
sequences, for the moment all the sequences are equal to 10;
- Change the survey layout to 'One page per section';
- Save the survey;
- Test the survey;
- Fill the 'Q1';
- Go to the last page and Submit the survey;
- Review your answers.
Before this commit, the question is empty, this occurs because the
question page_id is not set, in _compute_page_id, the sequence of the
question should be bigger than the question of the page (in this case
the section).
Now, the _compute_page_id was change to take into account the case when
the question has the same sequence as the page (section).
opw-2222045
closesodoo/odoo#49366
X-original-commit: 99f35075e3d1e418e096a29b7440152e746a1cd5
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Typo was preventing create multi to multi create.
closesodoo/odoo#49352
X-original-commit: 2c65b7283a37b8c44d91e01112843882098bfc7b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Install Projects
- Change language
- Check projects
There is a word "X Tasks" which is not
translated.
Cause
This is a model attribute which is not
translatable. It can have any value
"Tasks" is not mandatory.
Solution
Make it translatable
OPW-2233084
closesodoo/odoo#49346
X-original-commit: 587160376237a12a9174ad5c4578a273b48ca489
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
SIPS sometimes send empty notifications. I have been unable to find out
why or to reproduce the issue; it seems to be linked to a delay on their
end since these notifications usually arrive after a customer is
redirected back to Odoo (at least on their test account).
I'd rather log a warning for those cases (since nothing is wrong on
Odoo's side, there's just no info to act upon) instead of a full
traceback.
closesodoo/odoo#49335
X-original-commit: 100ef1bdb7b90edbeccfa6cd10297acb824b8083
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
SIPS date format can be somewhat variable, some sanitation is required
before using the data raw for the ORM.
opw-2224926
X-original-commit: 620e987f326d6da7c3a9b2c1aca7bff16d9ce6c4
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Before this commit, the test assets were called with a `t-call-assets` and contained
themselves some other `t-call-assets` to the back-end assets. According to the current
specification, having nested `t-call-assets` will result in a compilation of the
lower levels regardless of the current debugging mode.
Now, the test bundles (desktop & mobile) have been arranged so that their `t-call-assets`
are all called on the same level.
closesodoo/odoo#49306
Related: odoo/enterprise#9797
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, When using the "Generate a Payment Link" button under the
Action menu (model=account.move), the last step of the flow is "back
to my account" , But this button doesn't generate any actions. If you
click on it, nothing happens because the button "Back to My Account"
was overlap by the payment logo.
So in this commit, we add fix the layout and use the row so the
elements do not ovelap each other.
Task-Id : 2197705
closes odoo/odoo#49012
Closes: #49012
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Install eCommerce
- Create a SO
- Add a section
- Add a note with big text
- Customer Preview
The word are not broken correctly
Cause
We added a break-all to prevent
long URL/words overflow.
Solution
Use work-break: break-word which
will break the word correctly.
Use overflow-wrap/word-wrap
(same usage but we need both
to ensure browsers compatibility)
which makes sure the long string
will wrap and not bust out of the
container
OPW-2222814
closesodoo/odoo#49321
X-original-commit: 0754590abe1b84874aa2a685fea5cbf2569383e4
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Steps to reproduce the bug:
- Let's consider a consumable product P with an internal note IN
- Create a SO with P and confirm it
- Print the delivery slip
Bug:
The internal note NI was displayed on the delivery slip.
opw:2227613
closesodoo/odoo#49277
X-original-commit: 038221f3180a7a8888503553dbb5eb57875ef3a6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Create a product with UoM Dozens
Sold 5x via POS
Go to the product page
The smart button does not reflect the correct quantity
(0.42 instead of 5).
Fixing by editing the SQL query, the POS already provide
the correct quantity of sold goods as it is not possible
to change the UoM. This aim to match the behavior of sale (where
is necessary to account for possible differences between the uom
reported on the sale order line and the one specified in the product
page)
opw-2227482
closesodoo/odoo#49313
X-original-commit: 7af831fe47005c6a7724d8d28bf3d045a75f0f09
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Filter out section and notes from the invoice status computation.
opw-2233550
closesodoo/odoo#49301
X-original-commit: 55d3c59235cadb70aa9206eaec7ff1e4631fb019
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Also non-browser jsonrpc (as it goes through a similar process): for
internal performance reasons, name_search and read_group have been
converted to a *lazy* name_get, so the "display name" is not
unnecessarily computed.
However this is an issue for the RPC endpoints (/xmlrpc and /jsonrpc)
as they have no support for `lazy` and thus tend to blow up and / or
do the wrong thing when trying to output a lazy:
* xmlrpc has no way to handle lazy at all and straight blows up
* jsonrpc falls back to `json_default` so they try to stringify the
lazy, which might have worked except
*Problematically* both endpoints delegate the actual work to
`dispatch_rpc` which handles dispatching between various services and
ultimately creates a *new* cursor before calling model
methods (`object` service and `execute`/`execute_kw`).
This means by the time the result is serialized to be output, the
lazy's cursor has long been closed, and thus any access to an
unevaluated `lazy` errors out when trying to fetch the underlying
item.
This also means we can't just add a hook to serialize the lazy
in the xmlrpc marshaller, though we do have to do that. We *also* (for
both xmlrpc and jsonrpc) have to force evluation of lazy values before
our cursor is closed, meaning it has to be done right after the method
is invoked, iterating the entire response.
Related to task 2170343
closesodoo/odoo#49286
X-original-commit: e2b5a359c1d5eccbe725c1c3169b4130d7bca49b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Update information in JS doc for 13.0 (replace control panel mixin with the hasControlPanel attribute).
closesodoo/odoo#49291
X-original-commit: 0d46f49a00c6ecb62725ab97c1f337d1b0666852
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
1/ Recurring Events
==============
TL;DR A bit of magic and ... Pouf ... all virtual events are now real records.
## Purpose
The current implementation of recurring events uses "virtual events" to represents all
events in the recurrence. Only one event is stored in the database. All other events are
dynamically built and sent to the web client which sees them as real records.
This implementation is old, difficult to read (6 years of changes and bug fixes) and
has become more and more difficult to maintain.
A fresh start would be welcome.
## Specification
When creating a recurring event, a `calendar.recurrence.rule` record should be created.
This model holds the rrule configuration and is responsible to manage events that result
from the rrule.
When a new recurrence is created, all resulting events are also created (stored in the
database). No more virtual events.
To avoid an explosion of events, a maximum of 720 events is created. With 720 events,
a daily recurrence lasts for 2 years and a weekly recurrence lasts for 15 years.
This strategy is used by Google Calendar and seems acceptable in most cases.
A cron job could eventually be introduced to generated more events as the end comes.
This allows to introduce an new rrule end type: 'Forever'. This is actually a shortcut
to create a recurrence running for 720 events.
Inspired by Google Calendar, new possibilities are introduced when modifying a recurring
event (e.g. change the name, add an attendee):
- Modify only this particular event (the event is still part of the recurrence)
- Modify this and following events (events are still in the same recurrence)
- Modify all events
In a similar way, when updating the rrule of an event (e.g. from every Monday to every
Tuesday), the user can choose to:
- Modify this and following events: the recurrence is split. The first part remains
unchanged but now ends when the second recurrence begins. The second parts is the
updated rrule.
- Modify only this particular event.
- Modify all events: Forbidden (same as Google Calendar)
Note: when events are "moved" because the rrule changed, the events are not actually
moved. They are unlinked and new events are created (See "Some design choices explained"
section).
## Some design choices explained
### Where to store the rrule?
Two options were considered.
1) Store the rrule on an event, each event of the recurrence having a Many2one
to the parent_id, aka the Master Event of the recurrence.
2) Store the rrule on another model: `calendar.recurrence.rule`. Each event in the
recurrence having a Many2one to the recurrence record.
Both options have pros & cons. But there is no clear winner.
However the actual business logic of handling the recurrence creation/update
would be the same.
Where the rrule configuration is stored is the only main difference between both options.
And this is probably the easiest part of implementing recurring events.
With that in mind, option 2) is chosen. It allows to clearly separate recurrence
logic from the events themselves. It is also the "correct" way of modeling data to avoid
many empty columns for most records.
### Reusing events on rrule update
When an rrule is modified, events should also be updated.
In most cases, current events are unlinked and new events are created from scratch.
Only events exactly at the same time before and after the rrule update are kept.
Trying to reuse other events would require an obscure and arbitrary heuristic.
(Imagine an rrule every Monday that is changed to every Tuesday and every Friday.
What would you do?).
This implies that any change to a specific event (name change, attendee added, chatter
messages) is lost. This tradeoff seems acceptable as updating an rrule should not be
that frequent. Moreover, Google Calendar also works that way so why not Odoo?
### Reusing events on events shifts
On the calendar view, drag and drop an event to shift the entire recurrence.
One way to handle the recurrence shift is to apply the same timedelta to all events.
Now events are correctly positioned... except for events that were specifically
moved. Those outliers needs special handling.
This also introduces some behavior inconsistencies:
when an rrule is directly modified, events are not reused, but when the rrule is
modified by drag & dropping an event, events are reused. This option needs more code to
handle the shift and the behaviors are not consistent.
The chosen option is to find the rrule configuration from the dragged event (this is
easy) and update the recurrence with those new rrule values. This brings us back to
an rrule update (see above): code reusability yeah; one behavior to rule them all yeah.
One downside is that outliers are lost (but Google Calendar also works that way).
2/ Synchronization with Google Calendar
==============
This commit refactors calendar synchronization between Odoo and Google after the
main calendar application refactoring.
This refactoring takes advantage of two new features from the Google API:
- New way of synchronizing resources efficiently[1]
Incremental sync is performed repeatedly and updates Odoo with all the changes that
happened ever since the previous sync. Each time, Odoo provides the previous sync
token it obtained from Google and stores the new sync token from the response.
- Event metadata[2]
Ability to set hidden key-value pairs with an event, called extended properties.
These extended properties are used to store the related odoo event id and the Odoo
owner id (see known limitations)
### Known limitations
- Let A and B be two new users (no tokens available). A creates an event in Odoo and
invites B. A is the owner of the event (user_id). Now B authenticates to his Google Calendar
account and synchronizes his calendar. We cannot send the event to A's calendar since we
don't have any access to his Google Calendar. Hence the event his sent to B's calendar.
This leads to data de-synchronisation: The owner is A in Odoo but B in Google.
The "real" owner (user A) is stored in the Google event's metadata to be able to
reconcile the owner for following synchronizations.
- Let A and B be two users of Odoo and Google Calendar. And let the Google Calendar of B
be private (e.g. if A creates an event in Google Calendar and invites B, B won't see the
event in his calendar). If A creates an event in Odoo and invites B. The event is synced
to Google Calendar of A. Now B can see the event in Odoo but he can't see it in his
Google Calendar.
Task 2126717
PR #42031
PR Enterprise https://github.com/odoo/enterprise/pull/8006
[1] https://developers.google.com/calendar/v3/sync
[2] https://developers.google.com/calendar/extended-properties
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
To change your Google Calendar account, the authentication tokens must be set to `False`.
But doing so leaves synchronized events in the database.
This commit adds a wizard to handle those existing events as the user wants.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
This commit refactors calendar synchronization between Odoo and Google after the
main calendar application refactoring.
This refactoring takes advantage of two new features from the Google API:
- New way of synchronizing resources efficiently[1]
Incremental sync is performed repeatedly and updates Odoo with all the changes that
happened ever since the previous sync. Each time, Odoo provides the previous sync
token it obtained from Google and stores the new sync token from the response.
- Event metadata[2]
Ability to set hidden key-value pairs with an event, called extended properties.
These extended properties are used to store the related odoo event id and the Odoo
owner id (see known limitations)
Known limitations
=================
- Let A and B be two new users (no tokens available). A creates an event in Odoo and
invites B. A is the owner of the event (user_id). Now B authenticates to his Google Calendar
account and synchronizes his calendar. We cannot send the event to A's calendar since we
don't have any access to his Google Calendar. Hence the event his sent to B's calendar.
This leads to data de-synchronisation: The owner is A in Odoo but B in Google.
The "real" owner (user A) is stored in the Google event's metadata to be able to
reconcile the owner for following synchronizations.
- Let A and B be two users of Odoo and Google Calendar. And let the Google Calendar of B
be private (e.g. if A creates an event in Google Calendar and invites B, B won't see the
event in his calendar). If A creates an event in Odoo and invites B. The event is synced
to Google Calendar of A. Now B can see the event in Odoo but he can't see it in his
Google Calendar.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
[1] https://developers.google.com/calendar/v3/sync
[2] https://developers.google.com/calendar/extended-properties
The fields `start_datetime` and `stop_datetime` are the exact miror
of fields `start` and `stop` respectively.
The field `display_start` is never used.
Hence those fields are removed.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
Payam Yasaie