When saving a description the one edited doesn't appear but the one edited
previously instead. This fixes this problem.
Technical note: the default description for a new event was the rendering of
a template. That template was shared between all the events and overridden each
time.
The solution was to strip the identity of the template while rendering it
making it a constant and preventing it from being shared between events.
This could be done by setting rendering_bundle to True in the rendering context
(unfortunately, t-ignore is not a legitimate attributes of template tag).
Note that the same fix [1] was done on `website_hr_recruitment`.
[1]: https://github.com/odoo/odoo/commit/f1ee633f26a78636fede3e2b600c801b5f474a50
Task-2781443
closesodoo/odoo#89520
X-original-commit: 5e8be9024b8fd1cdd7caf3cb711861a4a7bee2c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The Italian edi system accepts utf-8 encoded documents, but actually the
contents of the fields have to be latin-1 encoded. Format-alphanumeric
should remove any non-latin1 characters and replace them with a ?
Several fields to are also truncated before the function is applied.
This is so that these fields better match the specification. This will
help to prevent edi rejections in the future.
A test is also included to test with a few lines that should / should
not be adapted in by the format_alphanumeric function. Along with the
addition of the test, the test partner italian_partner_a's is_company
field is changed to True, since the partner is a company. The expected
xml has been altered to match the changes to partner_a.
closesodoo/odoo#89494
Task-id: 2826424
X-original-commit: 712758fc2505abfa271636caaa8ba38436086f32
Signed-off-by: Josse Colpaert <jco@odoo.com>
Purpose
=======
Avoid calling _recompute_rank for users that are not affected by the
newly created/written ranks, by filtering users by karma_min
Task-2746929
closesodoo/odoo#89463
X-original-commit: 3a0562ea809b5ba40a66fa4a996424696320f91c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
Avoid sending lost of emails for new ranks rank for each user when
installing gamification module.
Emails are now only sent outside of module installation.
Task-2746929
X-original-commit: 5dc3b3ef794b78f18713b4bcf6254ab60d62eec4
Part-of: odoo/odoo#89463
Steps to reproduce the bug:
- Create a manufacturing order to produce “Table”
- Confirm and plan the MO
- Start the work order
- Cancel the MO
Problem:
- The work order is cancelled, but the timers continue to run.
- "Block", "Unblock" and “Unplan" button should be hidden when MO is cancelled
opw-2817842
closesodoo/odoo#89442
X-original-commit: 5682015958d03f4a65969afe3fce9b9b05e5b505
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
For an imap "PEC server" we will fetch mail and set \Seen flag according to
current value.
But the way imaplib was used seem to possibly cause an issue on some
particular mail providers.
Mailing RFC* gives example of adding flags with parenthesis around flag:
eg. "A003 STORE 2:4 +FLAGS (\Deleted)"
but we are sending these command wihtout parenthesis (which seems to be
working, but apparently not for some providers).
To fix this issue, we change how we use the API to do the same thing
than in fetchmail module that is a lot more battle tested (and from logs
is sending flags in parenthesis).
* https://datatracker.ietf.org/doc/html/rfc3501#section-6.4.6
fixing #89305
fixing #81443
opw-2714596
closesodoo/odoo#89379
X-original-commit: 7dd5437a65bd43a91d6ae7e2fb4f11f2f0b1476b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
*: base_automation, iap, web_tour
Previously, when trying to create a custom dialog, one would need to
extend the base Dialog class and configure it directly on the class,
using separate templates for the body and footer as necessary. This is
very unidiomatic owl code, and it is much more natural to simply extend
Component, and use Dialog at the root of the template, giving it slots
and props to configure its properties and contents.
This commit changes the dialog API to work as described and adapts code
that uses it.
closesodoo/odoo#89113
Enterprise: https://github.com/odoo/enterprise/pull/26462
Related: odoo/enterprise#26462
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce:
- define a home action for the user
- delete the action in configuration > Window Action
- refresh to the home page
-> id not found
Solution:
- prevent the deletion of a window action if used as a home action
OPW-2728824
closesodoo/odoo#89420
X-original-commit: b868583690d8560d3cc300b9448f0af32f41d81a
Signed-off-by: yosa-odoo <yosa@odoo.com>
Before this commit, Barcode was not displayed on template
when related product variant is archived.
Here we are making sure that even when a product is
archived, its barcode is still visible in template.
closesodoo/odoo#89363
X-original-commit: f0c7cde3938c01df5fc10bb8dcd72fd3bb18afdb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Issue: when using Amazon's SES SMTP service they rewrite the Message-Id of all
outgoing messages. When someone replies, In-Reply-To contains the SES Message-Id
which we don't know. Threading is therefore broken. Amazon requires to remember
new Message-Id and handle it ourself, which is complicated [1].
Possible solution: copy the Message-Id to References in outgoing message as if
we were pretending that the message is part of a pre-existing thread with
itself. Since Amazon does not alter References it is kept during transport.
Replies will therefore contain both Amazon Message-Id and Odoo Message-Id as
well as original parent Message-Id in case of nested replies.
* ``In-Reply-To``: Amazon Msg-Id
* ``References``: Odoo Parent Msg-Id Odoo Msg-Id
Task-2643114 (Mail: Message-Id in references to ease thread formation)
[1] https://docs.aws.amazon.com/ses/latest/DeveloperGuide/header-fields.htmlclosesodoo/odoo#89328
X-original-commit: bc568747bdf92c6bbca400ce3ba11f6487679f3a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Followup of odoo/odoo@de7c119e66 where the parent finding was incorrectly refactored.
Indeed due to a typo new_parent was not updated. Instead of getting higher in
the parent chain until the first message, only the first parent's parent was
considered.
Moreover ``_mail_flat_thread`` is incorrectly taken into account. Due to the
hereabove issue it was not really impacting discussion channels, as anyway
parent finding was not working.
New parent management, depending on ``_mail_flat_thread`` is now
* ``_mail_flat_thread`` True: no free message. If no parent, find the first
posted message and attach new message to it. If parent, get back to the
first ancestor and attach it. We don't keep hierarchy (one level of
threading);
* ``_mail_flat_thread`` False: free message = new thread (think of mailing
lists). If parent get up one level to try to flatten threads without
completely removing hierarchy;
Tests show that parent is correctly flattened on business documents and left
untouched for channel-like documents.
Task-2822652 (Mail: fix parent message fetch / flattening)
X-original-commit: 86f21c1f384e37a4555b4b1ce4831904c8d40b6f
Part-of: odoo/odoo#89328
Purpose is to test behavior when having multiple references in mail headers.
We have to check that parent_id is correctly taken (as it impacts internal
flag), and that flattening is performance when posting the message (always
attaching to the thread first message being the default behavior).
Note that tests highlighted that flattening is currently a bit broken as it
does not go up until the first ancestor, which is the expected behavior for
business documents having ``_mail_flat_thread``. Next commit will fix that.
Task-2822652 (Mail: fix parent message fetch / flattening)
Task-2643114 (Mail: Message-Id in references to ease thread formation)
X-original-commit: f7d4f1d29213c71e76564c485db2bbecf0bbf37c
Part-of: odoo/odoo#89328
Avoid calling with_user() inside method has_group() when possible, as it
represents a major overhead inside this method which is commonly called. This
sole optimization speeds up the accounting general ledger by about 6%.
closesodoo/odoo#89206
X-original-commit: e858507aaf01c3701bf5642978490d7947acf35d
Signed-off-by: Raphael Collet <rco@odoo.com>
This task will:
- Clean the code (e.g. the production's moves are now created directly)
- Have the same behavior when creating object in the UI or directly in
backend
It's mainly on the `mrp.production` object and most of the computed
stored field are used as default value or act like an onchange on draft
production. Once the production order is validated, it's only modify
by direct write
Task-2709753
closesodoo/odoo#83576
Related: odoo/enterprise#24405
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Fixed the TestPurchaseInvoice.test_double_validation and the setupClass
to use test accounting data in setupClass instead of the demo data.
closesodoo/odoo#89370
X-original-commit: a7546aead36c5d56809fcd9c46b2a552991b5449
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
When having a subview for a 2many field, if an onchange is triggered for
that field, the default values of the parent are still in the request
context.
To reproduce the issue:
(Need helpdesk_repair. Use demo data)
1. Helpdesk > Configuration > Helpdesk Teams, edit "Customer Care":
- Enable "Repairs"
2. Create a storable and tracked-by-usn product P
3. Update the on-hand quantity:
- 1 x P with serial S
4. Helpdesk > Customer Care (Tickets), create a ticket:
- Product: P
- Lot/Serial number: S
5. Click on Repair and save the repair order R
6. Edit R and add a line in "Parts"
Error: on the new line, both Product and Lot/Serial fields are already
filled with values P and S, which does not make sens
On step 5, when clicking on Repair, the form views of a repair order is
loaded with a specific context:
https://github.com/odoo/enterprise/blob/deef3c967d43862edf02dbcfc461fb89b064731e/helpdesk_repair/views/helpdesk_views.xml#L31-L34
Therefore, when editing the form and trying to add a new line in Parts,
an onchange is triggered but the default values are not removed from the
context. As a result, since the model `repair.line` also has two fields
called `product_id` and `lot_id`, the default values of the parent
(`repair.order`) are used.
When computing the context of a subview, the default values of the
parent should be removed.
OPW-2752436
closesodoo/odoo#89366
X-original-commit: db7423a97fd812fe6df95296fd7a6ca18854933b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Create a 15% tax [TaxA] *not* included in price
Create a 15% tax [TaxB] included in price
Create a fiscal position mapping TaxA to TaxB
Create a customer and assign this fiscal position
Create a product :
Price = 100€
Tax = TaxA
Create a SO with this customer and this product
We have this situation
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 115 | TaxB| 100 |
While it should be
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 100 | TaxB| 86.96 |
after tax mapping, as it was before
https://github.com/odoo/odoo/commit/625486a8382fde9033b73e2a4b4e7713cf4131c1
opw-2811596
closesodoo/odoo#89361
X-original-commit: 1a5b2b44c63afb302a2d6fc1e841e4ef3af46df5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
before this commit,
in project form view alias_name field label color and padding are
different then other fields.
after this commit,
alias_name field label color and padding will be same as other.
field' label color and padding.
task-2758779
closesodoo/odoo#89329
X-original-commit: d33a839c1047a3abfa681611ae5276e0b929b555
Related: odoo/enterprise#26473
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit:
in task search view quick search on user_ids return active and
non-active tasks of user.
this commit remove active_test false from context of user_ids' quick
search so it should only return active tasks of user.
task-2758779
X-original-commit: 6148736215fe91d1eb1b19fd08809bdfe5a61fe2
Part-of: odoo/odoo#89329
before this commit,
in kanban view of task sub-task count of task is visible when
sub-task feature is disable from setting.
after this commit,
sub-task count of task will not be visible in kanban view of
task when sub-task feature is disable from setting.
task-2758779
X-original-commit: 1e45586c16443c3a19ae16f604882087dea3cc4e
Part-of: odoo/odoo#89329
This PR fix the "This attachment is already a document" Error when clicking on the "Apply Changes" button of a mrp.eco (Engineering Change Orders) in the PLM App.
With the Documents App installed and the "Product: Centralize files attached to products" document setting activated, copying the attachment will also copy the document.
Then when we try to copy the current document and link it to the new attachment, the above mentioned error appear.
The context no_document=True prevent the document copy during the attachment copy.
OPW-2762448
closesodoo/odoo#89324
X-original-commit: ed306afc0e812c1e42984f1b6cb94e61409f0144
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
The putaway strategies are not correctly working with packages
To reproduce the issue:
1. In Settings, enable:
- Multi-Step Routes
- Storage Categories
- Packages
2. Create a Storage Category SC:
- Allow New Product: mixed
- Max Weight: 100 kg
- Capacity by Package:
- 1 x Pallet
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Package type: Pallet
- Store to: WH/Stock
- Having Category: SC
5. Edit the warehouse:
- Incoming Shipments: 2 steps
6. Create a product P:
- Type: Storable
- Weight: 1 kg
7. Create a planned receipt R:
- To: WH/Input
- Operations:
- 100 x P
8. Mark R as Todo
9. Create two packages:
- 50 x P in PK01 (! PK01 must be a Pallet)
- 50 x P in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer T
- Error [1]: Both packages are redirected to L01, but the capacity
by package is 1 x Pallet. PK01 should be redirected to L01 and PK02 to
L02
12. Set the done quantity of PK01
- Note: PK01 is now redirected to L02
13. Set the done quantity of PK02
- Error [2]: PK02 is also redirected to L02. Again, it violates the
package capacity constraint
**Context**
When validating the receipt (step 10), it creates a picking
Input->Stock. The module then tries to assign some quantities, which
leads to `_prepare_move_line_vals` for each package. In this method,
`_get_putaway_strategy` is called to define the best destination of each
stock move line:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1313
The computation of the best location is in 3 phases:
- Phase 01: `_get_putaway_strategy` finds the relevant putaway rules and
computes the current and forecasted stock related to the current
package/product
- Phase 02: `_get_putaway_location` checks if, considering the putaway
rule and the current package/product, a location can be used
- Phase 03: `_check_can_be_used` checks if a location can receive a
package/product (considering the weight and the capacity constraints)
**Error 01**
During the first phase, in case of a package, the forecasted quantities
are computed by searching all SML that have the same package type:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L258-L263
This can not work. The SML used to move the product in PK01 (from Input
to Stock) is created but its field `result_package_id` is not yet
defined. This operation will be done at the of the assign process,
thanks to:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1547
So, during the first phase, when searching a location for PK02, the
computations are not aware that PK01 is already sent to L01. This
explains the error [1].
**Error 01 (Other examples)**
Considering how it is currently working, we could imagine another
problematic use case: 2 different products on the same package. Since
there is one SML per product, `_prepare_move_line_vals` will be called
twice (as well as the putaway strategy process). It may lead to two
different locations while the product are on the same package.
**Error 02**
When setting the done quantity, an onchange method is triggered:
https://github.com/odoo/odoo/blob/4202e46a8313fa9f1487d372ef0cb771f769be8d/addons/stock/models/stock_move_line.py#L200-L208
and tries to find the best location, considering the done quantity. As
said before, during the first phase, it looks for the current and
forecasted stock of a location. Since it will find the SML we are
writing on, the parameter `additional_qty` is used to subtract the
quantity of this SML (we need to ignore the current SML's quantity). But
here is a new issue:
https://github.com/odoo/odoo/blob/4202e46a8313fa9f1487d372ef0cb771f769be8d/addons/stock/models/stock_move_line.py#L217-L222
`_get_putaway_additional_qty` returns the quantity of products while the
first phase is looking for the quantity of packages. As a result, we do
some operations between products and packages:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L290-L292
`qty_by_location[location_id]` is 2 (i.e. PK01 and PK02) for L01 while
`qty` is `-50` (i.e. the 50 products of the current SML), so the value
becomes `-48`. This can not work properly because the value doesn't have
sense anymore. Later on, during the third phase:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L340-L346
The forecasted weight is not subtracted by the quantity of the current
SML. So the weight is exceeded, this is the reason why the destination
of PK01 becomes L02 on step 12 (it will be the same on step 13)
**Additional error**
Suppose the user is receiving a tracked product (suppose qty > 1). When
confirming the picking, several SMLs are generated to "reserve" the
quantity from the customer:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1469-L1471
Later on, thanks to the wizard `stock.assign.serial`, the user generates
all USN. However, because the option `show_reserved` is disabled, the
wizard creates some new SMLs. But here is the issue, the SMLs created
during the assign process are already existing. Therefore, when looking
for the best location (for the new SMLs), the existing SMLs will disturb
the result (`_get_putaway_strategy` will find these SMLs and think that
some products are already incoming in some locations)
**Solutions**
- We should compute the best locations once all SMLs are created (and
linked with their package)
- In case of a package with a type, we should try to find the best
location for the package itself, not for each product of the package
- When calling the putaway strategy process, we should provide the
SML(s) to exclude instead of providing some quantities. This will
prevent subtracting products with packages and allow the correct
calculation of the forecasted weight for each location
- When creating a putaway rule, we ensure that the option
`show_reserved` of the destination location is enabled
OPW-2746169
closesodoo/odoo#89350
X-original-commit: 98169b391f4610545b7f4745b729ad95eac3696a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When selecting a quotation template for a quotation all the template lines are
copied into the quotation. However, the sequence field is omitted when adding
the lines. As a result all quotation lines have, by default, the same sequence
number.
This should not be a problem, since the lines are still shown in order in the
frontend quotation view. Once the lines are shown, the user can freely reorder
the lines, while the frontend takes care of reordering the sequence numbers.
However, there is an interaction with an existing problem in One2Many and
Many2Many fields. When these fields are paginated a sequence update will only
update the sequence numbers on the first page. This means that, before this
commit, when we move around a line on the first page, all the lines on the
second page will be inserted at the second position on the first page (because
of the way _onResequenceRecords is implemented).
This commit does include the sequence number in the copied quotation lines,
resolving the problem described above.
Note: It is still possible to insert new lines in the first page, extending
the sequence numbers at the end of the page. Since the sequence numbers on the
second page still remain the same, there are now lines on the first and second
page having the same sequence numbers, resulting in a similar bug.
opw-2730746
closesodoo/odoo#89344
X-original-commit: 6f11060d6afd9edce904dd34a2d415a2a2461108
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
These tests fail non-deterministically.
The underlying problem is currently being fixed.
But to fix runbot issues, the tests are skipped in the meantime.
Note that the failure in tests show very rare buggy behaviour,
but the buggy feature is very minor. So it's reasonable to not
obstruct mergebot by just skipping tests while a fix is being
prepared.
closesodoo/odoo#89384
X-original-commit: a51a636bc3acdab3700323a825c77ba4572e942f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Ensure the `onChange()` callback is called
after each history steps in the editor.
Call the `_doAction()` directly, to avoid using the
disabled `_doDebouncedAction()`.
task-2760436
closesodoo/odoo#89339
X-original-commit: 18eaabcb4dab4682e3a94e16dbe66ff3c6f35a77
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
The costs and revenues stat button on the project form view
should not be present since the saas 15.1, so we hide it.
closes odoo/odoo#89359
Related: #75269
X-original-commit: 6a508b351419a7edbc8276a8174ea60859b24dda
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
In case there is an AML with 0 qty, the generation of the FatturaPA e-invoice
tracebacked. Even if it's a functional error on the invoice, this also impeded
the EDI cron to run, and this is solved by avoiding the case in the
computation.
closesodoo/odoo#89348
X-original-commit: 79cbea8b9241c1fa98db1bb575ea430360d630e3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
This commit moves some business logic from components to models,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2826823
closesodoo/odoo#89323
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
lines
Create test directory for l10n_it_edi_sdcioop, and relevant tests for
the exported xml. These tests are run in l10n_it_edi_sdicoop because
there is different behaviour when l10n_it_edi_sdicoop is
installed (different checks are run on the invoice).This module should
eventually be merged with l10n_it_edi in master.
closesodoo/odoo#89207
X-original-commit: dffb205dad9ce29288c82c4b51011b77ddf33580
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
### Current behavior before PR:
The `product.template` model has a nice function `create_product_variant` that unfortunately expects its input to be in JSON.
### Desired behavior after PR is merged:
JSON decoding is moved into the controller, such that the function can be called as expected.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#88989
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the mass mailing form, when clicking on the filter save button, the screen
was unexpectedly scrolling down. This fixes this problem.
Task-2793090
closesodoo/odoo#86789
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Create a storable product with routes: MTO + Buy
- Create a Portal user “pu1”
- Create a SO > select the “pu1” as customer
- Validate and confirm the created PO
- Connect as “pu1”:
- Go to the sales order view:
Problem:
The client can see outgoing and receipt(PO picking) transfers, this is a problem because then the customer can see information from the vendor
Solution:
A portal user should only see outgoing type transfers in the sale order view
opw-2816719
closesodoo/odoo#89285
X-original-commit: 91cfdf997dd210f2cbc684674745ab0b251088d2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, when the Project Manager wants to see the burndown
chart report, he cannot see all the tasks if the project visibility is
follower and he do not follow the project. Indeed, he can only see the
ones in which he is assigned or follower. This behaviour is not expected
for a project manager but only expected for a project user.
This commit adds a rule to avoid filtering the records from burndown
chart report when the current user is a Project Manager.
Related PR: #82634closesodoo/odoo#89284
X-original-commit: f045bd78d562ec48762479138bc8388af252d06a
Related: odoo/enterprise#26457
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The accounts Furniture and Equipment, Computer Hardware &
Software and Motor Vehicles had the wrong type (Current assets)
we changed it to match egyptian fiscal law (Fixed assets).
opw-2821715
closesodoo/odoo#89280
X-original-commit: 315b3b13644dcad007ae9efd1a22bb32f64da143
Signed-off-by: Josse Colpaert <jco@odoo.com>
Bug
===
If the user doesn't have access to the project / CRM module, those
menus were visible on the addin side.
Now, the sections are not visible if the user doesn't have access to.
Task-2765323
closesodoo/odoo#89260
X-original-commit: 7b7aa72ecdc7e69e425ae08c28e1e7827e423548
Related: odoo/enterprise#26446
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Allow to re-use the method `mock_auth_method` used to mock the Outlook
authentication, to be able to write tests in other sub-modules.
Task-2782150
X-original-commit: 6932f05bfc4b2beabaf7c6390f1d241fff73bd38
Part-of: odoo/odoo#89260
Finetuning of 970904b06f6872aadf69d64c7bc82072a16f1596
Only update the template (& reset the lines if change done through UX) if
the SO wasn't saved already to make sure existing setup is not reset.
This commit restores even more of the previous behavior when the template
was only defaulted to the current company one. Now the default is only
modified if you change the company before saving the record.
In all other cases, the template can only be modified manually/programmatically,
but won't be reset/updated by the compute method.
Task ID - 2798588
closesodoo/odoo#89255
X-original-commit: 7209e391789be6a807bd4eac22257e888cbaf1a6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Pierre-Yves Dufays