Traceback generated when trying to pass a datetime object into a function tag
in xml.
<function name="action_name" model="model_name" eval="datetime.date.today"/>
Used to fail.
With this commit now one can pass time, datetime, timedelta, relativedelta,
version, ref, pytz in function tag in xml
Task-id: 1772614
Closesodoo/odoo#29212
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Dhaval Limbuwala <dli@odoo.com>
If destroy is called before start, there will be a crash before this commit.
At the time of this commit, this can be reproduced in master by dropping the
image gallery snippet, clicking on add images (double click, which opens the
media dialog twice for some reason), selecting 2 images to add on the
media dialog, and clicking on add. The error will be in the JS console.
closesodoo/odoo#33440
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Open a mail.compose.message wizard.
Select a template that generates an attachment.
Reselect it. A second attachment has been generated.
Can be repeated ad infinitum.
At template onchange, the template is rendered to overwrite the composers values
This includes the attachments.
Let L1 be the list of attachments generated by the template.
When _convert_to_write(values) is called with {'attachment_ids': L1},
it gets self.attachments_ids = L2, and generates a [(6, 0, L1 + L2)] command.
As a result attachments are only added,
the previous ones need to be removed manually.
Since c6d718f, the semantics of _convert_to_write changed.
Before, it always returned an empty list for new records (without an id).
In other words, wa always had L2 == [].
As a result we need to adapt the wizard to keep its old behaviour.
To solve it we bypass the _convert_to_write for 'attachment_ids' and directly
generate the 6 command with the list of ids L1 generated by the template.
We only do this for templates that add attachments to keep the templates
composable (a template only overwrites the values it defines).
Unfortunately, we don't have any way to know which attachments have been added
manually, so we can't preserve these (which was the old behaviour anyway).
opw 1997430
opw 1987169
opw 1998115
opw 1998782
closesodoo/odoo#33387
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When multiple emails (`mail.mail`) are linked
to the same message (`mail.message`),
all the message notifications were being marked as sent
as soon as one of the mail was sent, and not all of them.
This is indeed possible to have multiple emails linked to a single
message, for instance when there are employees and customers in
the followers of a thread, and some must therefore have
the buttons meant for the employees ("Assign me") and some not.
In other words, it was possible notifications were marked
as sent while their associated email was not sent yet.
This revision also comes as an addition to
5d6656d739
as it was possible to receive a bounce coming from
the previous mail sent which wrote on the same notifications `email_status`
than the current message being sent before we could acquire the lock on
them (see commit message of the above mentioned revision),
as it was writing the `email_status` on more notifications that it
should have, including notifications of the previous email.
e.g
- Mail 1
- Message 1
- Recipient A, B, C
- Mail 2
- Message 1
- Recipient D, E
Let's say recipient A bounces
If the email notifying the bounce arrives during the processing of the "Mail 1",
it will be blocked until we release the lock on the `mail.notification` `email_status`
we acquire thanks to having written `exception` on `email_status` before sending the email.
But, as soon as it is unblocked (after the `cr.commit()`),
it will immediately re-attempt the delivery of the bounce email,
therefore writting "bounced" in `email_status` of recipient A,
while the transaction of the second email already began.
When the second email sending will try to write the `email_status`
of recipient A as well
(as it used to write the `email_status` on all the message notifications,
not just the one related to the current email),
it raised a concurrent update.
Therefore:
1. Interrupting the loop, as psycopg2 exceptions are raised and not passed,
2. Replay the sending of the second email a second time.
opw-1984293
closesodoo/odoo#33431
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Since cdca5d4751, the field company_id
on account.payment is not stored anymore, so, it doesn't make sense to be able to group on it
OPW 1998427
closesodoo/odoo#33428
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
If the smtp session was dead, it would lead the whole mail batch to fail.
opw 1949270
closesodoo/odoo#32424
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
closesodoo/odoo#33350
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When an exception is raised during the course of a normal SMTP session,
smtplib's `sendmail()` method will close the channel automatically,
so any further attempt at sending SMTP commands will fail with an
SMTPServerDisconnected error, even just calling `smtp.quit()`.
This will shadow the original error, and make debugging harder.
Fixes#1493
The purpose of this commit is to allow to define lead generations rules based on the website visited.
Task-ID: 1964025
closesodoo/odoo#33391
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In order to make the overview more understandable, we provide some modifications:
- remove some value when they are zero ("No task found", ...)
- the whole middle column (percentages) is merged inside the hours one
- provide some tooltips
- renaming titles
- ...
To do so and to avoid leaving empty lines or doing complicated template branching, the
above table is split in two different tables, so that we can remove lines independently.
We also added a new category in the overview, concerning timesheets that are related to a cancelled so. This meant tweaking the project_overview plan_prepare_value method, in order to have the new numbers calculated and keep the others consitent.
Task-1968121
closesodoo/odoo#33015
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
If the user tries to save the recurrent event with 0 as the number of
repitations or interval there will be a traceback so instead of traceback
display the warning so user will not be able to save that event.
Task-1930809
closesodoo/odoo#31388
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Having :
- a pricelist with 10% of discount for all the products.
- the discount policy in the pricelist set to : "Show public price &
discount to the customer"
- a product with negative price (ex : -$125)
- add the product in a SO with the 10% pricelist
Before this commit, the unit price was the price with the discount
already applied: -$112.5, and not the original price as expected; The
subtotal price was $101,25 (the discount is applied twice) which is
wrong.
Now, the unit price is -$112.5 as expected, in Odoo surcharge are always
included in the display price.
opw-1986582
closesodoo/odoo#33717
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
oe_view_nocontent_smiling_face does not exists in css
when using this classname, the smiling face does not appear
closesodoo/odoo#33519
Signed-off-by: Christophe Simonis <chs@odoo.com>
When recreating the auto-generated view of user base.user_groups_view (e.g.
with a '-u base'), the view was generated in the language of the admin.
In case the database was in a different language than English, the source arch,
stored in database in arch_db field, was translated.
Instead, the source must be in English and translations must change the content
based on the user's language.
This was introduced at 894143cb4c as the view content was not translated.
At that time, the arch field was not translatable and the xml_translate mode
did not existed yet
Fixesodoo/odoo#33482closesodoo/odoo#33566
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create a lead without Salesperson assigned
- Edit the lead, set a Salesperson => the Assignation Date is set
- Edit the lead, change the Salesperson
The Assignation Date is reset.
There is no reason to change the Assignation Date in the second case.
Indeed, in many cases the Salesperson is modified for a good reason
(e.g. the first person left the company). From a customer perspective,
that doesn't change anything: he was always in contact with a
salesperson and the lead was handled. Moreover, the reporting becomes
incorrect.
We only change the Assignation Date if no Salesperson was assigned.
opw-2001912
closesodoo/odoo#33640
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a SO for a stockable product
- Validate the SO
- Change the 'Delivery Address'
Nothing warns the user that the address was not changed on the
corresponding pickings.
opw-2002084
closesodoo/odoo#33636
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase to reproduce:
- Install stock, mrp, purchase
- Go on warehouse form view
- Click on Routes button
Either one of the route manufacture or buy is missing.
All implementations/overrides of stock.warehouse._get_all_routes()
call their parent's implementation of get_all_routes_for_wh().
which is a reference to stock.warehouse._get_all_routes() but that means
that the route 'mixin' behavior can be skipped.
(the reference is to the base implementation of _get_all_routes())
Fixes#33286Fixes#33288
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When website_customer is not installed, some endpoints are not handled
by the router, causing the following tests to fail:
- test_10_crawl_public
- test_20_crawl_demo
- test_30_crawl_admin
Those tests were failing due to /customers responding with 404.
Indeed, the route /customers is defined in website_customer, but had
some usage within website_crm_partner_assign, causing tests to fail when
the former module is not installed.
The new behavior can be explained as follows:
- module website_crm_partner_assign on its own will lose the hyperlink.
- module website_customer will now inherit the view definition in order
to wrap the targeted HTML text elements with an anchor tag.
Closes#33344
Signed-off-by: Christophe Simonis <chs@odoo.com>
resolve_2many_commands() is bugged and returns different outputs for new
vs existing records. It is to be removed, so it is replaced with a call
to new()
closesodoo/odoo#33222
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this fix, in 12.3, with taxes affecting subsequent taxes' base, tax_ids was used to store the taxes whose tax lines impacted current tax line's base. Before 12.3, this field was used to store the taxes whose base line has to be impacted by the current tax line.
This old behavior was changed by mistake. We restore it for consistency.
closesodoo/odoo#33471
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before that, creating a tax without any repartition line with a company_id set in create() failed to create the default ones, because they did not receive the company they had to be created for (as 'company_id' was not passed to the default_get).
closesodoo/odoo#33617
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The method _renderCreate in the ManualLineRenderer was executed before
the call to super finished. Which makes impossible to create a writeoff
in the reconciliation widget.
closesodoo/odoo#33582
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
- On the invoice pdf, if the invoice is in USD, we
need to specify conversion rate and amounts in AED.
Also, if it is between certain Gulf states, you need
to mention this on the invoice. 'Invoice' also
needs to replaced with 'Tax Invoice'.
- Taxes changed to 0% and 5% / AED symbol on currency
adapted to the real situation of UAE.
- A tax by state automatically adapted with the fiscal
positions in order to have the tax amounts correctly
split by state in the tax report.
opw-1931322
updated to 12.3 taxes (and l10n_ae_reports removed in
enterprise)
closesodoo/odoo#33474
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
In Sales > Order > SaleOrder > Print > Choose Document Layout > Save: when data is saved there is comes a traceback as write method is called directly on Save button.
(sale_management)
Hence write method should not be called and args passed returns an empty list.
- we defined dummy method to be called on save
Similarly, in TimeOff > Reporting > Report by Department > Print > Choose Document Layout > Save and Print : write_company_and_print_report method is called on Save and Print button
(hr_holidays)
-write method which is called inside write_company_and_print_report is removed as empty args list is passed.
reference is taken from- https://github.com/odoo/odoo/commit/1ced3bfca457ac50845637bcd42a8e53bd7f088d
opw:1973947
closesodoo/odoo#33454
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Basic Chart of Accounts and taxes for the Mongolian
accounting. Tags for a lot of reports in Enterprise.
A lot of different taxes are created to be able
to represent them in the vat report. Mongolians
are used to taxes included even for B2B.
Some fiscal positions are added e.g. to automatically
apply 0% for export.
We got a lot of input from our Mongolian partner
Baskhuu Lodoikhuu and colleagues from BumanIT LLC
opw-1946238
Adapted to taxes in 12.3
closesodoo/odoo#33399
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Due to forward port, _onKeydown was declared twice.
This commit should fix an issue in mobile with Android 4.4 where
it's not allowed to have two functions with the same name.
Original Commit: a3d98dae68closesodoo/odoo#33495
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Consider the following use case:
- Two taxes:
-A: price included, affect base of subsequent taxes, 10%
-B: 15%, regular
- Create an invoice with a line applying A, then B, for 110€. Post it
- The following move lines are generated:
- base: 100€
- tax A: 10€
- tax B: 16.5€
Before this fix, line "tax A" only had the tax tags of tax A. It should also receive the base tags from tax B, in order to affect its grid total correctly in the tax report.
Also, tax_base_amount field used to be computed, but its computation was too simple, and most of the time wrong when doing advanced use of taxes like the one we defined above. It is now not computed anymore, and directly takes its value from the compute_all's result.
closesodoo/odoo#33420
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The goal of this commit is the alignment of the total in List view.
before this commit, it shows the left side so that it looks weird.
After this commit total show below the related column.
Task: 1981893
closesodoo/odoo#33210
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
- Activate cash basis
- Set a tax
Tax Due: Based on Payment
Include in Analytic Cost: true
- Create an invoice, add the tax and an analytic account on the invoice
line
- Validate and pay
The analytic account is correctly set on the tax line, but it is not set
on any of the cash basis entries.
Partial backport of 079a13a349.
opw-1971751
closesodoo/odoo#33236
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set a product barcode to a 8 letters value, e.g. 'AAAAAAAA'
- Print 'Product Barcode (PDF)' (or any other report containing the
barcode)
The barcode doesn't print.
All templates assume that:
- a 13 characters barcode is EAN13
- a 8 characters barcode is EAN8
But this assumption is too restrictive: one could want to generate
barcodes with such length without following the EAN13 or EAN8 structure.
We fall back on Code128 when the barcode generation fails.
Backport of 06cfdbaab8
opw-1981988
closesodoo/odoo#33240
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Christophe Simonis