Steps to reproduce:
- In Journals/Bills/Advanced activate "Lock post entries with hash"
- Create a purchase tax of 17%
- Create a bill with a product of a cost of 30 and apply the "17%" tax
- Post it
- Export the data inalterability check report
Issue:
"Corrupted data"
Cause:
In python we have a reprentation issue
```
>>> 30*0.17
5.1000000000000005
```
We define the hash string during the `_compute_string_to_hash` at the
move creation. The issue is, at that time, the move_line tax debit
is not rounded.
Therefore, when we print the report, we take the `move.line_id.
debit` from the db which is rounded and equal to '5.10' and compare
it to '5.1000000000000005' which gives a different hash
Solution:
Implementing a V3 version that uses `repr` for monetary fields.
opw-3072693
closesodoo/odoo#114567
X-original-commit: cfd71892aabf1510273b28032ff8f2d4cfd4d1f7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
To reproduce the issue:
(Also need: account_accountant,purchase)
1. Setup a product P
- Storable
- Category:
- FIFO + Auto
2. Process a PO with 1 x P at $10
3. Process a PO with 1 x P at $50
4. Create and confirm a SO with 1 x P
- Because of FIFO, the value of the delivered product is $10
5. Process the delivery
6. Post the invoice
7. Add credit note
- Credit Method: Full refund and new draft invoice
8. Post the second invoice
Error: The cogs are based on the second received product ($50), they
should rather be based on the delivered one
When computing the anglo-saxon unit price of the product, we consume
the outgoing SVLs, and we consider the already-invoiced quantity.
Here is the issue: we pretend that this quantity is 1, because of
the first invoice, but this should be balanced with the quantity of
the credit note
OPW-3109789
closesodoo/odoo#114564
X-original-commit: e46d68562c1ec55b7838f6854c1d26f56bec9bc6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit:
If a payulatam payment is received from the confirmation
page (so, with the webhook). If the value have some decimals
it might be rounded in the wrong way.
As such, the generated signature to compare with is wrong
and the payment validation cancelled
After this commit
If we cross compare the signature generation documentation:
https://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/response-page.html#signature-validationhttps://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/confirmation-page.html#signature-validation
We notice that the `new_value` computation is slightly different
depending on the return.
The one we currently use for both method is the "return"
one which is computed differently from the "confirm" one.
With this change of code a "confirmation" page payment
will be validated as intended.
I also changed the log level from warning to exception
so that the traceback and exception message is logged.
Before this commit there was just a generic warning message
opw-3018628
closesodoo/odoo#114552
X-original-commit: ee30c21eb5189b2cfcfd6d249985c947f759eaa2
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
Since commit 17a24020ac, StateSelectionField
displays its label in all views. This was an error. It should only
display its label in list views.
closesodoo/odoo#114538
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce the issue:
1. Create a product:
- Type: Storable
- Category:
- Costing Method: AVCO
2. IN 1000 @ 0.17
3. IN 800 @ 0.23
4. OUT 1000
5. OUT 800
6. Open the inventory valuation of the product
Error: the total value is $-6.00, it should be zero
Once all products received, the standard price is $0.20. Its value
has been rounded because the real value is
`(1000 * .17 + 800 * .23) / 1800 = 0,196666667`
The standard price will create a difference when using the products,
because:
`(1800 * .20 = 360) != (1000 * .17 + 800 * .23 = 354)`
That's the reason why a feature tries to compensate such rounding
errors. So, step 4, when preparing the values of the out-SVL, we
check if there is a rounding error, and we find a difference of $6,
which is correct. However, the difference is above the treshold, so
we will not consider it as a rounding error:
https://github.com/odoo/odoo/blob/3ff51daa93a1d670b8f67f79418d4dd48e94875f/addons/stock_account/models/product.py#L197-L200
Here is the issue: the threshold is based on the outgoing quantity
(1000) while the value difference is based on the whole quantity
(1800). This difference should also be proportional to the outgoing
quantity.
Note: The fix will still not work with a small quantity. The only and
best solution is to change the type of the SVL unit cost into a
float.
OPW-3101374
X-original-commit: 35d8b4c2a223970520961bf8bfc574bb309af090
Part-of: odoo/odoo#114525
Co-authored-by: Adrien Widart (awt) <awt@odoo.com>
Since [this commit], it's possible to change the connectors style in
edit mode, unfortunately the code to determine if the connectors should
be visible or not was not compatible with small width screens. As a
result, when a user edited his site on a small screen, he saved hidden
connectors even for visitors with larger screens (while the connectors
should be visible). This commit allows the user to manage the connectors
correctly without taking into account the screen size at the time of
editing.
Steps to reproduce the fixed bug:
- Drop a steps block.
- Reduce your screen width to < 992px or Switch to mobile view from 16.0
- Activate an option of the block.
- Save.
=> The connectors are not visible anymore in desktop view/large screens.
[this commit]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4
task-2687506
closesodoo/odoo#114447
X-original-commit: https://github.com/odoo/odoo/commit/6f507a315a64529627c8805d5947ffe4a7f6f509
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
*:point_of_sale,pos_restaurant,web
A new module pos_preparation_display has been added to Odoo enterprise.
This PR is intended to add the requirements necessary for it to work
properly.
The changes are mainly related to the kitchen printer functions, as
the pos_preparation_display module reuses these flows in order to
receivethe orders to be prepared.
closesodoo/odoo#109024
Related: odoo/enterprise#35392
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Those items are no longer used since the legacy form views have
been deleted from the codebase.
closesodoo/odoo#114394
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Allow to perform multiple reconciliation at once in order to:
- ...batch the creation of records as much as possible.
Creating an account.partial.reconcile force the orm to search for amls in order to invalidate the reconciliation fields like amount_residual/amount_residual_currency.
- ...reduce the number of flush inside the orm and batch the compute.
Each call to reconcile is looking for the payment's state of invoices before/after the reconciliation.
This step is costly because this will flush all the reconciliation data and then call the computes to get the fresh value of payment_state.
- ...modify more easily the way the lines are matched together.
Before this commit, the lines were split into two batches sorted by some criteria including the currency: debit and credit.
Then, we were matching them together sequentially.
Now, we make the same things except we do that first for each batch of amls sharing the same currency in order to reduce the number of cross-currencies reconciliation.
- ...allow the orm to prefetch all the partials in the reconciliation chain all at once.
The full reconcile needs to be creating on the full reconciliation graph starting on the current amls so we need to travel the matched_debit_ids/matched_credit_ids in order to find all the involved amls.
Fetching all this data at once is also reducing the number of queries made by the orm.
Let's take an example:
Suppose 10 amls: a1, a2, ..., a10
Suppose 10 amls: b1, b2, ..., b10
You want to reconcile respectively a1 with b1, ... , a10 with b10.
Before this commit, each reconciliation was done as follow:
- Check the payment_state of invoice (on 2 amls)
- Create a partial reconcile (single record)
- Create a full reconcile (single record)
- Compute the reconciliation data to compute payment_state (on 2 amls)
All of that, 10 times sequentially.
With the new '_reconcile_plan' method, we are able to give a list of recordset [a1 + b1, ..., a10 + b10]:
- Check the payment_state of invoice (on 20 amls)
- Create a partial reconcile (10 records)
- Create a full reconcile (10 records)
- Compute the reconciliation data to compute payment_state (on 20 amls)
For a reconciliation using 2000 records (a1, ..., a1000 & b1, ..., b1000), the time to reconcile it was about +-34 seconds. Now, it's about +- 3 seconds.
closesodoo/odoo#113680
Related: odoo/enterprise#37543
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- Install "Sales" module (for test purpose)
- Change company name to `בונז " ור מונד` (notice the double quotes)
- Go to "Settings > Users & Companies > Users"
- Select any user and then click on "send an invitation email" button
- Go to inbox and check the email
Issue:
No email received (at least not in main inbox).
Cause:
The email is not received in main inbox (Gmail or Outlook might flag
them since email from is not well parsed) because the `email from`
value is not escaped properly (by escaping the double quotes).
Solution:
Instead of using the company name (that is not escaped) and email to
build the `email from` value, use the company email_formatted value
instead (and fallback on user mail if not available).
opw-3097910
closesodoo/odoo#114534
X-original-commit: 0c4cb5e3cc2758cb27e94ecbbcfaa734ba5a50eb
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
The test TestWithholdingAndPensionFundTaxes::test_pension_fund_taxes_export
was expecting the xml to contain a tag `<RiferimentoAmministrazione>` while
this tag is optional if there is no description set, which is the case here.
We thus removed this tag from the expected xml.
closesodoo/odoo#113236
Related: odoo/upgrade#4359
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Taxes have a `description` field that has been hijacked to
represent tax label on invoices. We want the description field
to be used for its original purpose, thus created a dedicated field
`invoice_label` in which we transferred `description` content.
We also make description translatable.
This is part of the Tax Taxonomy 2 rework.
Task: 3052677
Part-of: odoo/odoo#113236
This commit allows the user to choose which quants to reserve from stock
and the quantity to reserve from each quant, making reservation much more
flexible from the picking form.
In addition, the `reserved_uom_qty` of stock.move.line
is now editable in views to allow for users to change the qty reserved
by existing move lines. When editing the reserved qty, if quantity is not available,
it will reserve only what is available..
closesodoo/odoo#106006
Taskid: 3090913
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit adds a check to avoid forcing a write on the sml
even if the putway location is the same on the sml, which
avoids unnecessary additional costly _gather() calls during the quant updates in the write
Taskid: 3090913
Part-of: odoo/odoo#106006
This commit fixes a couple of issues linked to relational fields:
- When previewing a file with relational fields/ids, they were not
correctly mapped to their respective fields in the selects, the fields
were also not correctly mapped in the arguments given for the import.
- The select label was also only showing the name of the last sub-field
while it should show the full path ("External ID" vs "Company / External
ID").
- Some errors were not correctly displayed: wrong field name, not in a
column when it should be.
Task ID: 3210337
opw-3203704 + opw-3192403
closesodoo/odoo#114490
X-original-commit: 871690afdc2ce4da2770a144cc4fc5ed038e6f73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit: if a different `web.base.url` is set with
`web.base.url.freeze`, during the first synchronization of Google
calendar it will show a mismatch URL error. The problem is that we
send the `redirect_uri` based on the `web.base.url` in the
`_get_authorize_uri` function.
The solution is to use the request root URL instead.
opw-3175539
closesodoo/odoo#114482
X-original-commit: 8f94f2ec864bdb54e3deb9b853a2720c5c92f592
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit, we will remove:
- groupedBy because the api is weird, we don't want to handle type abbreviations.
- getAggregableRecords because it is only used in one place.
In this commit, we will also convert canQuickCreate to utils and we will
move it to kanban because it is the only view that uses it.
Part of Task: 3179751
closesodoo/odoo#114459
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
ValueError "Invalid field slide.slide.partner.survey_scoring_success in leaf
('survey_scoring_success', '=', True)" .
it occurs because the domain field in gamification.goal.definition is not updated
when we uninstall the model.
we add the uninstall_hook in website_slides_survey where we replace the domain.
sentry-3779856181
closesodoo/odoo#114353
X-original-commit: abc662e3b190c58794eaf62ed7850439f9ebfd50
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If an user tries sending a invoice using an invoice address and a
delivery address through snailmail, it would result in a traceback.
This is due to the invoice address record not having a name.
closesodoo/odoo#114227
X-original-commit: eceb23b1835b3d039759eb7431950f221ac1fb6e
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The main goal of this commit is to simplify, uniformize and remove
unused props. The props removed are : options, attrs and className.
The readonly prop is uniformized with the one in the fields api. It will
now allow the use of readonly as modifiers on the widgets, as it's
already the case on fields.
This commit also uniformize the parseWidgetNode with the parseFieldNode,
the widget doesn't receive on props the rawNode anymore but a widgetInfo
as is the case for the fields.
Part-of task-id 3179751
closesodoo/odoo#114188
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
__Description of the issue this PR addresses:__
The first character of a Tax ID from Albania is a letter representing the decade in which it has been issued. The letter M represents the current decade. (This pdf explains in details how it is formated: https://www.oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/Albania-TIN.pdf).
Currently the way Albanian Tax IDs are validated is through the python library [`python-stdnum`](https://pypi.org/project/python-stdnum/).
However, the regex that is used to validate them has not been updated since 2017. (I made a PR in its repo https://github.com/arthurdejong/python-stdnum/pull/402 to fix that).
The code from this commit is inspired by the one from that library, but the regex includes the letter M.
__Current behavior before PR:__
(`base_vat` must be installed)
By going to Settings > Users & Companies > [A company]:
- Set the country to Albania
- Set VAT/Tax ID to “M12345678T”.
=> Error message
closesodoo/odoo#114488
X-original-commit: f0b6e4ccd8f7402a5d70b9d60d91e463073e5bde
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Step to reproduce:
Edit documents layout in general setting to add logo and background
select multiple documents (more than 5) e.g. Inventory> delivery slips
print all documents.
Bug:
background and logo missing on the last documents because the pages
were printed before the browser had time to render them
Fix:
wkhtml2pdf has a default delay of 200 ms (--javascript-delay)
increasing the value will allow large document to load
opw-2951594
closesodoo/odoo#114512
X-original-commit: ac2df93eb3f08696189d010bdfa4187e02a94576
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- Install `Contacts` module
- Create 3 contacts with the same name
- Archive one of the contacts
- Go to list view
- Edit search filter to display archived and non archived contacts
- Select the 3 created contacts
- Open `Action` menu and click on `Merge`
Issues:
- Archived partner is set by default as destination partner.
- Archived partner is not displayed in the list of partners to merge.
Cause:
- The default destination partner set is the last record of the record
set returned by `_get_ordered_partner` (where `Archived` partners
are the last ones in the record set).
- The field `partner_ids` does not allow archived records.
Solution:
- Sort the partners to have the archived ones on top (since we took
the last one).
- Set `active_test` to False in the context of the partner_ids field.
opw-3205577
closesodoo/odoo#114508
X-original-commit: 8d0cec6844b248d3787bd7d6b8868d930d25e38c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set the check number to 2147483648 and validate
- Create a new payment with the check method
- Click on Print a check
Issue:
Error is raised
Cause:
As for https://github.com/odoo/odoo/pull/112832 there is a second check in order to increment the check number
opw-3140973
closesodoo/odoo#114496
X-original-commit: 531147bb5fad6372c3742bc061f78687f7f11e5b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Before this commit:
- When a color index is greater than 55, the CSS class applied does not
have a matching style.
Only 56 CSS classes have a matching style: from 0 to 55.
To reproduce:
- Go to Calendar, edit an event and add an attendee having an id greater
than 55. When displayed, the event does not have a proper color.
It has the default FullCalendar color instead.
After this commit:
- The colors will cycle through 55 colors, from color 1 to color 55.
(Color 0 being the value for "no color", which is some kind of gray)
closesodoo/odoo#114491
X-original-commit: eda4e12202a1bf6459009b41313f9af4b4dc326b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.
The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.
Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.
opw-3133464
closesodoo/odoo#114472
X-original-commit: 6ae5d73332d5413495cc25e28cba86f8be18b570
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
RATIONALE
Currently email layout choice is done in code and is not controllable through
any user interface. In this commit we prepare improvements in template
management by allowing to choose the email layout directly from a given
mail template. As number of layouts is going to grow better be able to
choose the right one.
SPECIFICATIONS
Add a field on template to propagate email layout choice directly on
template and propagate it to the composer, then post/notify process.
We can now choose directly on a template which notification layout should be
used in conjunction with this template. Composer model already holds a field
'email_layout_xmlid', used in various places in code to give a specific
layout to use when sending notifications emails e.g. SO email layout. This
can now be specified directly from the template itself. It allows to
customize the look and feel of notifications without having to do it
explicitly in a given code flow.
Computation is coming either from template, either reset. When having a
template with a value set, set it on composer. When removing the template
reset it.
Currently no standard template uses it as this task targets mainly a code
cleaning that began with the composer code cleaning. It targets the near
freeze to have the base code updated once, then functional templates will
make use of it (hopefully).
Note that currently notification layout is still not supported at composer
level for mailings. It is simply ignored when generating outgoing mail
records. This will be improved soon.
Global followup of odoo/odoo#107356 / Task-2088884 (Mail: Use editable
computed stored fields in composer).
Prepares code for Task-3046371 (Mail: Better Language Support in Composer)
see odoo/odoo#106177 .
Task-3186426 (Mail: Support notification layout in template / email composer)
closesodoo/odoo#114462
Related: odoo/upgrade#4404
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We have a lot of hits without any forum_origin which will raise an
error 500 because this parameter is required. But because this params is
not into the controller but received as a get parameter, it will match
the controller and return an error 500 instead of a beautiful 404.
Some controller like 'open_partner' redirect to this url without the
parameter forum_origin too, leading in a 500 in all cases.
Better for uX to have this param, but not critical to display the page.
The only negative impact will be to have a 'Back' button that return to
this new default value '/forum'.
closesodoo/odoo#114461
X-original-commit: 991d1c430f2c9bb0d2b2d7ac8f75338eafd2aced
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Before this commit, in the forum post form view, the answers one2many
field is not aligned properly.
* open a forum post from website
* click forum post in the top bar (near edit button)
* forum post form will be opened
After this commit, the field will be displayed properly.
closesodoo/odoo#114433
X-original-commit: 5d8db1e1715cef36468681f59da55c780ae67a55
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, the model's record had two similar functions: isNew
and isVirtual, this commit will remove the isVirtual function to only use
the isNew one.
closesodoo/odoo#114431
Part-of: task-id 3179751
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When a portal client changed the quantity of an optional product on a
quotation while being in the portal the unit price of the product
was recomputed and we lost the unit price defined by the user on
the backend.
After this commit this issue will no longer occur.
opw - 3178262
closesodoo/odoo#114425
X-original-commit: bcd1a5820fe8250f50b4dc360ed1d0d48ae76b1c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Missing sudo for portal user on Invoice list.
When portal user go to his portal, to display the list of the invoices
we compute the url via get_portal_url that will call this method
`is_purchase_document` and got a traceback due to missing permission.
Now we call it with sudo to bypass the Access Right error without leaking
any extra information since it is casted as boolean later.
`get_portal_url` -> `record.access_url `-> `_compute_access_url`
account:account.move `def _compute_access_url` -> `filter(is_invoice)`
account:account.move `def is_invoice` -> `is_sale_document or is_purchase_document`
hr_expense:account.move `def is_purchase_document` -> `return bool(self.expense_sheet_id) or super()`
closesodoo/odoo#114424
X-original-commit: 01a91419f906bd8d9248e6376a0246b667218ca2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
1. Install [Studio], [Accounting] on Apps
2. Enter [Accounting]
- Click the Studio icon second to left on the top right corner
- [Edit Menu]
- [NEW MENU]
- Fill in e.g.`Test`, select [Existing Model], Model: Payment Methods
- Click the icon on the right, check it is `account.payment.method`
- [SAVE & CLOSE]
- [CONFIRM]
- [CLOSE]
3. Click on `Test` menu created next to [Configuration]
- [NEW]
- Type in all info, click to Save
- Error is thrown
Desired: block users from creating a `payment.method` by all means
Impacted versions: 14-master
opw-3148453
closesodoo/odoo#114408
X-original-commit: 59ea0e9802fc9cf98bab8fbdc065d9b5fc023ac7
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
When following recurring meeting are imported through google calendar
synchronisation, it happens that a meeting get unexpectedly
duplicated in Odoo, what will in turn duplicate the event on google
and send invitations to all the existing attendees.
As calendar.recurrence.calendar_event_ids is a One2many field,
the update using self was setting the base_event_id's recurrence_id
field to the last record of self recordset. Due to this, the event
will not be considered to filter out the existing_ranges in
calendar.recurrence._reconcile_events function.
Therefore, a calendar.event will in turn be created using the same
start and end datetime as the base_event_id of the calendar.recurrence.
OPW-3143680
closesodoo/odoo#114392
X-original-commit: d1587758ac642b0181e660ea48222385d01098e3
Signed-off-by: Arnaud Joset <arj@odoo.com>
Until now, if you search for /shop/Desk for a new link, you will not
have any result.
Now we search that it match *shop*desk* so /shop/custom-desk-12 will
match.
closesodoo/odoo#114357
X-original-commit: 84a407e744b7bacab43a0213ab52002a49c5d623
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
issue: When creating a sale order, with a service that involves the creation of a project, with analytic accounting activated, the default analytic account is not the default one set in the settings of the Project app.
Steps to reproduce the issue :
- activate analytic accounting in the Accounting app.
- in the settings of the Project app, set the default analytic plan to any value but the first one.
- create a product in the Sale app, with a product type 'Service', that involves the creation of a 'Project'.
- create a sale order with the product
- go in the analytic accounting menu in Accounting app
-> the analytic plan is not the one set by default in the settings of the Project app.
closesodoo/odoo#114302
Task: 3169483
X-original-commit: e801b3fa1bbc31713375cc669c6d47b32b175f53
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
When we added tables on a floor plan from the floor screen,
the tables stacked one upon another which was confusing and annoying.
Now the table will be added on a free place on the floor plan.
We also rename the tables: they are no more called "T1", "T2"
but "1", "2",...
closesodoo/odoo#114282
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Odoo does not have much in terms of payment protection; you can create
payments to any account you want without many checks.
This changes it by requiring users with the right groups to trust an
account before allowing it to be used for payment methods requiring.
Also adds some warnings on the bank account view, and checks at the time
of creating a payment.
Task id # 3210415
closesodoo/odoo#114278
Related: odoo/enterprise#37789
Related: odoo/documentation#3737
Related: odoo/upgrade#4397
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
william