In this commit -
1) Added new field propagate_carrier_id in stock.rule and propgate
carrier in PICK PACK and SHIP if it is ticked.
2) Allow to print Label at any stage of PICK PACK and SHIP after
validation of picking from chatter.
Task-2363484
closesodoo/odoo#62851
Related: odoo/enterprise#15148
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before the commit, if an exception occurs there was an error saying:
`TypeError: _handle_exception() takes 2 positional arguments but 3 were given`
Impacted versions:
- 12.0
- 13.0
- 14.0
X-original-commit: 47d6fa4ff6e78a33691c22b08504ce03e6796c9a
This provides a standard CoA with basic taxes and
fiscal positions.
closesodoo/odoo#68156
X-original-commit: eb41f0de553906e09d199190544c878a9d1a7e85
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
To reproduce:
1. set WH receipt in 3 steps
2. create a "receipt in 2 steps" route for product
3. create a PO with product "receipt in 2 steps"
In inventory, we will see this product still follow the "receipt in 3
steps" route.
This is caused when we create move for PO, we prepare the route_ids
according to warehouse's route_ids. After the move has it's own
route_ids, it will not search for route set on product or product
category (which should has higher priority over warehouse route).
To fix it, we remove the route_ids when create the move for PO. A route
will be found when the move being comfirmed.
Task 2448439
PR #65509
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
We also inject a context key to ignore prediction in case account_predictive_bills (enterprise) is installed. This way, having the same label on invoice lines generated by the helper will still behave in the same way, even if enterprise is installed.
closesodoo/odoo#67998
X-original-commit: b6c37754532ae6a7cc1f68a345fde6258abdc893
Related: odoo/enterprise#17125
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Add an additional report called "Voucher/记帐凭证" to print option in
account.move form view.
A library "cn2an" are required to conver a number to "amount in
words/大写金额" for Chinese financial usage.
Task 2179744
closesodoo/odoo#68121
X-original-commit: 0f6fdce76809af7e965f672970d74594a337f6fb
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit when we update the email_from field on lead with only
formatting differing from partner a warning ribbon was displayed. It
considered email had changed and had to be propagated. Moreover unnecessary
update on partner was done to propagate the new email onto the customer.
In this commit we propagate email only if normalized versions are different.
It means that if lead email_from is "Hermes Conrad <email@example.com>" and
partner email is "Jonathan Conrad <email@example.com"> no update from lead
to partner is performed. Indeed normalized versions are the same.
Task ID-2461308
PR odoo/odoo#66890
X-Original-Commit odoo/odoo@3dd972c35bclosesodoo/odoo#67859
Related: odoo/enterprise#17191
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to improve phone, email and mobile synchronization
tests for lead / partner. Notably
* mobile is not synchronized: only a void mobile is set to partner's mobile
when changing partner. It is not synchronized back onto partner;
* email / phone are correctly synchronized;
* phone_sanitized is computed on both lead and partner based first on mobile
then on phone. It means records having the same phone numbers could have
different phone_sanitized values if mobile numbers differ;
Task ID-2461308
PR odoo/odoo#66890
X-Original-Commit odoo/odoo@0adecd9a6e
Steps:
- Install Projects
- Go to Settings / Translations / Languages
- Install Dutch
- Go to Settings / Users & Companies / Users
- Edit demo:
- Language: Dutch
- Go to Projects
- Click the three dots on the first project in the dashboard
- Click Share
- Select demo as recipient
- Send
- Go to Settings / Technical / Email / Emails
- Click the email you just sent
Bug:
The email is not translated in the partner's language
Explanation:
The context of the template didn't take the current partner's language
into account since it was out of the partners loop.
The subject of the email wasn't aware of the partner's language as the
context hadn't been changed.
Wrapping the translations with the right `lang` context value fixes the
issue.
Also, the subject used the formatted string as the translation source.
This makes it impossible to find a matching translation since the source
is different every time.
opw:2475398
closesodoo/odoo#68162
X-original-commit: e446233a1b454ab1aa883609fd0b8a588fec9f00
Signed-off-by: backspac <backspac@users.noreply.github.com>
Steps to reproduce the bug:
1/ Install these apps: Sales, Planning, Employees, Project, Timesheets
2/ Add some employees (stay below 20 employees)
3/ Create a project with Planning, Timesheets and Billable
4/ Click on the overview
Bug:
List of all employees
opw:2460616
closesodoo/odoo#67850
X-original-commit: 3cf66c4ed482bb14973b57cacbe4ca56b93650d2
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previous default website logo of the 'website' module ('YourLogo'
image) looked like a text and not like a proper logo, so it has been
replaced by a more stylised, gray-coloured, version, as a svg.
--
task-2448746
closesodoo/odoo#68075
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Odoo has made some modifications to the method
_compute_invoice_taxes_by_group from de Account module,
so we need to update the inherited method in the argentinian localization
Improves:
- Don't depend on price_subtotal to compute amount_by_group
- Show taxes when they are zero on invoices print
closesodoo/odoo#68178
X-original-commit: 011631a38564bcbdd8625428b9f897aefefce270
Signed-off-by: Josse Colpaert <jco@openerp.com>
The problem that occurs before of this commit, is due the base of the taxes is in the currency of the company not in the invoice currency. For that the value that shows in this cases for the base is not correponding for the symbol of the currency.
After this changes we show the correct value an symbol for the base converting the value when is necessary.
X-original-commit: 4fd4f82ecd1b97f608168baaa780844f68e8a9d7
Purpose of this merge is to provide some fixes and additional tests for
event mail schedulers.
Notably
* do not autocommit when running event mail schedulers in test mode
* allow event user to confirm registrations even with mail schedulers
* respect scheduled date when calling mail schedulers execute
Improve tests.
Related to Task ID-2414658
COM PR #68158closesodoo/odoo#68167
Forward-port-of: odoo/odoo#68158
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We do not want to fail ever if loading the attachment fails.
We still log a warning in every case though.
Some malformed PDFs lead to seeking the wrong bytes while looking for
some parts, raising a ValueError
closesodoo/odoo#68171
X-original-commit: f4cc0579a3e0ee9c117c7dd0f6090edc6e94384d
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
In this commit we ensure calling ``execute`` method on communication schedulers
do not send emails or SMS if their scheduled date is still not achieved.
Currently only the cron method does it (see ``run``).
It is now safe to call ``execute`` directly on event communication schedulers.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 353bc5de9fafbc1527c382614e02438ee799c8a4
Due to ACLs it is currently impossible for event users to confirm a draft
registration if schedulers are involved. Indeed it implies updating the
scheduler which is not do-able for them.
In this commit we sudo the update of schedulers, as this is a technical
object and access is granted through registrations.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 73d09268922a7d242af85e36a3d81ed25ab4ca33
In this commit we improve event communication scheduling tests. We make tests
more detailed and use mail tools to ensure content. We also check scheduled
dates and use freezegun to ease date management.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 1a66d9cb57dc17b697b7a56effa91de3a4b50bd7
Otherwise it creates a lot of issues in your tests and database. Always avoid
that kind of error-prone statements in testing mode.
Related to Task ID-2414658
COM PR odoo/odoo#68158
X-original-commit: 3ad9126375e74071fec47f402f1fc63f98b755b6
A context is attached to the ValidationError object when elements in the
view arch are broken. This context helps to locate the error in the
source file. When the view processing fails outside of the arch
evaluation, such context is missing.
closesodoo/odoo#68157
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Issue:
In case of MTO on the component tracked by serial of the subcontracted
MO, if the picking generated by the MTO is complete
before record component on the subcontracted picking, when we
record the component, move lines is duplicated, one for the
reservation (due to the MTO chained move) and a other only with the
quantity done. Then it is painful to register component.
Fixes:
Don't the call of `_set_qty_producing()` when we click on
'Record Component', the user should it self applied the `qty_producing`.
closesodoo/odoo#68151
X-original-commit: e61ae06572db8aa5d1c3ecea754d3be6719eb55b
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before 1721ec1363 and fdc4ef97c9, Odoo did work fine when the
user had another default schema than 'public'.
This commit restores this behaviour by searching
for existing objects in the user's current schema,
which is the first in the schema search path and
the one used when no schema is specified when
creating objects.
closesodoo/odoo#68144
X-original-commit: 223781b34afacd1c0c5674d395cece6d472b048c
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit fix a bug introduced in #66551 where a mismatch has been done between
session.user_context.allowed_company_ids and session.user_companies.allowed_companies.
This commit also adds the following tests:
- a JS test in order to prevent future unwanted issues regarding multi company
in BasicModel.
- a Python test in order to ensure that session_info['user_companies'] is not
involuntarily changed.
closesodoo/odoo#68025
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Remove legacy arguments (`subdir`, `pathinfo`) of `file_open()`,
they were not used anymore and made the code more complicated
- Drop the long-deprecated support for files inside zip archives,
considering that zipped modules were discontinued a long time ago:
278ed718e9
- Remove the redundant `_file_open()` method, that should never have been
called directly anyway
- Add the possibility to filter allowed file extensions, in order to
avoid opening up access to arbitrary addons files, such as .py files,
depending on the context of use
- Split up the verification of the file path, to make it accessible
without actually opening the file, as a separate `file_path()` function.
closesodoo/odoo#68043
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Current behavior before PR:
mail notification not sent when using the full composer.
Desired behavior after PR is merged:
mail notification will send when using the full composer.
LINKS:
PR https://github.com/odoo/odoo/pull/66421
Task-2446855
closesodoo/odoo#67933
X-original-commit: 349f07670ea4938e7fc3d9fa3a6fc5fae40dac65
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit aims to allow ones to customize the condition whether the
optional column dropdown should be rendered or not.
PR enterprise : odoo/enterprise#15205
task-2392303
closesodoo/odoo#66979
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current rules would allow through a selector of the form
:not(sel1, sel2)
then because the matcher thing just splits on `,` it would store the
incorrect sections
:not sel1(
and
sel2)
as separate selectors in the rules cache, raising an exception when
matching against elements.
Move all the rules to a single regex, and add a rule to exclude any
situation where a comma or an open parenthesis is inside of an open
parenthesis pair: we can't just check if there's a closing parenthesis
with no intermediate `,`, because the selector could be
:not(:nth-child(3), sel2)
in which case the selector would "pass" as the regex would match the
nth-child's closing paren to the not's opening. This means some
selectors *could* be unnecessarily blacklisted, but currently we don't
have any such nested pseudo-classes so...
If we want to resolve this, we need to actually parse the
selector (using something like Sizzle I guess) in order to properly
split the selector-list and take a real look at the selector's
structure. Maybe one day.
closesodoo/odoo#68093
X-original-commit: d50c3b07f1c0644ac8e412f099ddd7b139671060
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
_snailmail_print can be called on multiple letters, and this can lead to a timeout from IAP Service. However, letters are sent, credits are consumed, but letters aren't marked as sent. To avoid that, we force the sending to IAP service to be done letter by letter.
closesodoo/odoo#68107
X-original-commit: 3d8ad1e68583fa1b354ff36f902ccb0405270bb2
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps to reproduce the bug:
- Create a multi-company environment with two companies A & B
- Create two sales taxes TA & TB, one for company A & one for company B
- Created a shared product P and assign both TA & TB
- Login with user having access of both companies
- Open POS session and select P
Bug:
A traceback was raised
opw:2422866
closesodoo/odoo#68102
X-original-commit: c087868a9a2b0aed22e8418b120f849bf680f918
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Valuation
- Click on export all (little button next to "Inventory at date")
The field "Total value" have too many decimals: 60739.2000000004
This occur because of the multiplication: it yield the correct value
(60739.2), but every rounding attempt done, even in the ORM, will
mess up the representation
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
opw-2438384
closesodoo/odoo#67558
X-original-commit: 67cf82962688360cfe25c6b2118a7dbd17a6ee95
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps to reproduce the issue:
- Let's consider a product P (11€) with a 10% included tax T1
- Let's consider a fiscal position FP that mappes T1 to a tax T2 (0%)
- Let's consider a website that displays prices with tax included
- Let's consider a portal user PU with FP as fiscal postion
- Log with PU
- Go to the shop and filter products to see P
Bug:
The price of P was 11€ instead of 10€
PS: When adding P in the cart, the correct price is displayed.
opw:2472528
closesodoo/odoo#68081
X-original-commit: e7bfadea847012ee956b7bb425688b5f9ccda9cf
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When Odoo routes incoming emails it is looking for existing messages in
database using Message Ids which are coming from e-mail header
References.
In Odoo the message id looks pretty long like
743570479975566.1584086032.522504091262817-openerp-message-notify@ip-172-31-45-160
As it declared in [RFC2822] long header bodies can be "folded" using
CRLF+WSP. And some mail clients do that very thing. They split
References header body which contains Message Ids by "\n ". The example
of mail client where it can be reproduced is apps.rackspace.com We
created Sales Order in Odoo, sent this quotation to the client email. He
replied with e-mail, and this email can't be matched with any existing
message id and as result it's not attached to the Sales Order.
RFC2882: https://tools.ietf.org/html/rfc2822#section-2.2.3closesodoo/odoo#68077
X-original-commit: 559f6cf62711ad45557eddec3af7c66616724eb5
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Payments made on eCommerce via a payment acquirer (i.e. Stripe) generate an
"account.payment" record where connected user's "child" partner is used for
partner_id of the payment, instead of commercial partner, as it is done for
payments registered on invoices.
For consistency, commercial partner should also be used for these payments.
opw-2457390
closesodoo/odoo#68065
X-original-commit: b738068be53621b23d9f19befdfdef50534ef434
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Create an internal user with ONLY the following rights:
* Point Of Sale: User|Administrator
* Purchase: User|Administrator
- Connect with created user
- Open a POS session and validate an order
- Close session
- Validate closing & post entries
The access is denied when trying to create account move due to following rule:
"Purchase User Account Move".
When validating session and creating account move, sudo is applied if user has no
"create" right on "account.move".
In the particular case where user is a purchase user or admin, he also has "create"
right on "account.move" and sudo is not applied when validating session (as it would
have been if he has no purchase rights).
However, as defined by "Purchase User Account Move" rule, he is limited to account
moves where type is in ('in_invoice', 'in_refund', 'in_receipt').
But the account move created when closing and validating session is of type "entry",
and therefore user cannot validate session.
A POS user should be able to close and validate a session, either he is a purchase
user or not.
opw-2456783
closesodoo/odoo#68060
X-original-commit: 4779ff2369f1f632429f5305bc4a84db730c3dfe
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The code from v13 used to look for partners in JS before making the RPC, which
was much faster, and also gave better results by returning partners that were
already known and therefore more likely to be selected.
The same logic is reintroduced here, and further improved to take into account
all known partners and sort them according to the likeliness they will be
selected based on various criteria.
task-2413776
closesodoo/odoo#68045
X-original-commit: 930e090ced8134c3819a5a87b9052467ba23e8e4
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Issue
- Install "Accounting"
- Change user language to arabic
- Go to Customer Invoices list view
- Try to filter on field "Created On"
Traceback is raised from the DatePicker Component
Cause
The cause is two fold:
There is an issue in moment that behaves abnormally when its internals
are not able to extract the month in a locale, and, instead of returning an
invalid moment, it returns a valid moment with the month set to January
which just happens to be the first month of moment's default locale
ref: https://github.com/moment/moment/issues/5600
Secondly, the defaultProps "locale" of the DatePicker was set to moment.locale()
at the file's initial loading, that is, before any user locale parameters were loaded
The bootstrap datepicker was then set with the wrong locale, and the case fell under moment's issue
After this commit, the locale of the DatePicker is always the one of the user, and there is no traceback
opw-2460156
closesodoo/odoo#68059
X-original-commit: e2c46bb80e1e312dd34ac554d79813ef35282e62
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Before this commit, calling unpatch on an object that hasn't been
patched before crashed (before reaching the code that handles the
case by throwing an Error). This scenario is now properly handled.
This commit also defines specific Error classes for the patch and
unpatch faulty cases, so that they can be elegantly catched (in
tests for example).
closesodoo/odoo#68057
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
In tests, we might want to disable a specific patch for a specific
test (e.g. to remove a monkey patch done when another addon is
installed, to test the behavior of the current addon).
Before this commit, it was possible to unpatch at the beginning of
the test, but we couldn't re-patch when the test was over.
Feature required by task~2392303
Some customers are scared of clicking on a button that says "Accept &
pay" directly from an email.
So, instead of using the online features, they download the PDF, sign it
and return it.
It seems legit, due to the text that you can read, so as an UX
enhancement, I propose to change that button's text.
@Tecnativa TT27664
closesodoo/odoo#65597
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In simple search by qty_available we use optimized method. Before this commit
that method didn't work when product doesn't have stock moves and domain
includes zero qty, e.g. ``[('qty_available', '>=', 0)]``, ``[('qty_available',
'=', 0)]``, etc
The problem comes from https://github.com/odoo/odoo/pull/66652closesodoo/odoo#68042
X-original-commit: 629ce193e4725919c1aeede000517564f0e8adf1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
The error message raised when linking a wrong SOline and a task used
unclear/incomplete information.
This commit improves the displayed message, replacing:
* the SO id by the SO reference, since record ids are not really useful to
end users.
* the product name by its display name, to include variants details.
closesodoo/odoo#68041
X-original-commit: 8db6e654a50d38001c42247b33392aad90cab821
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Pratima Gupta