This reverts commit 7273719b88.
Reply to header of templates should be used only for mass mailing purpose.
It is a known limitation and should not be changed in table without more
in-depth testing.
closesodoo/odoo#35354
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If in web_studio we:
- duplicate "Invoices" report
- delete "Invoices" report
The duplication will not work anymore, since the report class
report.account.report_invoice_with_payments is shared but requires
account.report_invoice_with_payments (original report).
With this changeset, we forgo checking model type of report since it
should always be account.invoice anyway.
opw-2045435
closes#35349
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When the scheduler needs to create a new PO to resupply a product,
it tries to use the 'supplier currency' on the vendor if set,
and defaulted to the currency of the current user's company.
However the scheduler is run in sudo, so the user is OdooBot,
which means that the currency is incorrect if OdooBot is in another company.
The company that should be used is the one that is used everywhere else.
opw 2041798
closesodoo/odoo#35285
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, the duration (days/hours of the leave) wasn't
compute when importing leaves.
opw-1916913
closesodoo/odoo#35167
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When using the "test import" feature to import leaves request
allocations, odoo fails with a 500 error and no error message.
The only difference with an actual import is that the test dry-runs by
roll-backing. The issue here are that mails are sent *after* a commit
is done hence crashes because they do not exist any more.
Fine-tuning of c7b6fcb9f2 for
hr.leave.allocation
opw-2041872
closesodoo/odoo#35166
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Unset the default sale tax on the company
Make a customer invoice
Add a line
Before this commit, the tax on the line was the purchase tax
because of a funky "if"
After this commit, no tax is set on the line
It is worth noting that archiving taxes shouldn't affect this flow
as it is the user's reponsibility to di his set up correctly
OPW 2043477
closesodoo/odoo#35271
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In some cases, when changing in the inventory setting from tracking lots and
serial numbers to not tracking, an issue could occur when trying to close the
MO with processed work orders and lots.
opw:2040752
closesodoo/odoo#35250
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In saas-14, 36fdb2ff49 was recently added to fix the flow where an empty
pricelist code being submitted in the cart input should reset the pricelist.
But we waited 12.0 to add an easy test, as we have `MockRequest` to easily
mock and simulate frontend context to test controller in python tests, see
6ebcb1db80.
Following #34711closesodoo/odoo#35253
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the amount total of an order in round_globally
was simply the sum of all taxes amounts, then rounded
This is plain wrong, as the accepted semantics of round globally is that:
- each tax for each line is computed without rounding
- then each taxes is summed across all order lines
- then that amount is rounded
- then all those rounded tax amount are summed together
After this commit, this semantics is implemented
closesodoo/odoo#35211
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since f98470e6cf, the 'user_email' field on project.task is
'related_sudo=False', checking access rights when fetching the field. For performance issue,
we need to keep this fix (as badly explain in commit above).
But, this causes multi company problem. Here are the steps to reproduce:
1/ User 1 (in company A) creates a task in a project (all in company A)
2/ user 1 switches to company B
3/ user 2 (in company A) tries to access the task and get an error, as it tries to access
a field 'email' of 'res.users' as himself (not 'sudo'), but the user is in a company that
user B can not access, hence the error.
The fix is quite simple here, as the problematic field is not used in the kanban view. It
does not solve the source problem, but the user is not blocked anymore.
opw-2041982
closesodoo/odoo#35243
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Before this commit, it was not possible to install website_forum if the 'Main
Frontent Layout' had been COW'd.
When loading Forum Layout view which is a primary child view, it would crash
during view validation, not finding the element to xpath.
Triggering COW instead of copying fix the issue.
opw-2036119
closesodoo/odoo#35138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Enable the rtlcss library, translate the website into arabic, add a
carousel. The previous left appears right on the screen and the next
right arrow on the left.
This fix is to invert the two value (left arrow/right arrow) when the
screen in RTL-ed.
rtlcss documentation is available at:
https://rtlcss.com/learn/usage-guide/value-directives/#tip
opw-2041898
closesodoo/odoo#35220
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, the placeholder for the website was incorrect, it
missed the protocol. This could lead to a confusion to the user who
could add a website without protocol. A website without protocol will be
open in the browser as a page of the same website and not as an
independent website.
Now, the placeholders have the correct protocol.
opw-2042816
closesodoo/odoo#35217
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In particular, the problem forbids a user to lower quantities on a SO
if the responsible is currently in another company.
- Install sale_stock and sale
- Activate Multi-companies
- Create Company A and Company B
- Admin in A and B
- Other user U (e.g. duplicate of Admin) in B only
- U creates a SO with a product, confirms it
- Admin connects to Company A
- U decreases product_uom_qty in a line
- U gets an AccessError
When decreasing the quantity, in sale_stock,
_log_decrease_ordered_quantity is called and calls stock's _log_activity,
that needs access to the responsible or the superuser's partner.
If that user is in another company, this raises an AccessError.
Because it is when accessing the partner that the AccessError is raised,
we cannot cleanly use a check_access_rule to determine when to use sudo.
OPW 2036879
closesodoo/odoo#35132
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Spec
====
Before this commit if a user has access to a document thanks to an access_token,
he would already be able to see the chatter for the document, but he would not
be able to download the attachments that are shown to him on that same chatter.
The goal of this commit it to let the user download those attachments. This
makes sense especially since messages publicly posted in the chatter might
generate emails to the user, and the attachments will already be attached to
those emails, so this PR is not actually granting access to more information to
the user in a typical flow.
The only difference is when said user was added as a follower after the
attachments have been posted in which case he will be able to read them even
though he didn't get the original emails, but this is consistent with how he
will also be able to read the existing messages even though he didn't get them
by email.
Technical
=========
To solve this issue we could have used the access_token of the main document,
but this would allow any user with the token to access all attachments of the
document, including those he should potentially not be able to see such as those
from internal notes.
Instead we ensure a different access_token is properly set on each of the
attachments that are going to be shown and we update their links accordingly.
This allows for a more granular access control, and it also takes advantage of
the existing /web/content route without having to adapt it.
opw-2040455
Also discussed in task-37264
closes#34384closesodoo/odoo#35121
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Co-authored-by: Pratima Gupta <pgu@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Backport from 12 to saas-11.3 (original commit : 97b44806f5)
Having 4 products and 3 BoMs:
BoM 1:
product = Finished
quantity = 100 units
- Semi-Finished 10 units
BoM 2:
product = Semi-Finished
quantity = 10 units
- Assembly 10 units
BoM 3:
product = Assembly
quantity = 10 units
- Raw Material 10 units (product.product 5$/unit)
Before this commit, the price for 100 units of Finished product was
500$, which is wrong. The price was calculated using 100 units of
Semi-Finished product and not 10 units as it should be.
Now, the price is 50$
opw-1973347
closesodoo/odoo#33115
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
closesodoo/odoo#34900
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Register a payment on a vendor bill.
From the menu Account > Purchase > Payment, clik to see that payment
click on the smart button to see the invoices
Create a new Bill
Before this commit, the default type and journal of the new bill were actually the ones of a customer invoice
After this commit, those defaults are the ones of a vendor bill
OPW 2038786
closesodoo/odoo#34967
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Activate option to pay invoice on the portal
Activate an acquirer with the mode: handle payments in Odoo
Make an invoice for a partner
Access that invoice through the route with the access_token
You should not be logged in !
Try to pay, with stripe for example
Before this commit, there was a cryptic error syaing that the credit card ID was invalid
This was because the transaction token was created on the public user
While we tried to access it as the invoice's partner
After this commit, there is no error as the transaction token is on the invoice's partner
OPW 2034691
closesodoo/odoo#34919
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit extends the changes introduced by 88de93114 to adapt
Odoo payment flows to the switch in transaction signature done
by Authorize.net.
The initial fix was not sufficient for flows that mixed redirection
payment flows and server-to-server flows (e.g. paying a quote with a
card that gets saved then using the token to pay for a subscription).
The problem comes from the fact that the server-to-server API uses
the API Transaction Key and API Login ID as credentials to authenticate
requests; there is no need for a signature since this data is never
publicly exposed on the website and a MITM is mitigated by the fact
that it would need to be done between the Odoo server and the
Authorize.net servers (both of which use https in a normal deployment)
which is admitedly more complex than doing a MITM on a Starbucks wifi.
On the other hand, the 'redirection' flow will include all transaction
parameters as inputs in an html form, therefore the signature is
required to ensure that the values have not been modified by a website
user or a mitm.
Since both flows can coexist on the same configuration, we cannot use
the same field depending on the payment flow configuration - we need
both fields to be stored for the provider.
This commit therefore has to introduce new fields on payment.acquirer
record that can store the signature key for authorize in addition to the
usual authorize fields. Instead of adding a new module, this commit uses
non-stored computed fields that will generate System Parameters entries
for any acquirer of the 'authorize' kind when set through the interface.
closesodoo/odoo#34670
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
If "Recurring Cost Amount" is set on a frequency and the date field
"Contract Expiration Date" is not set, the configuration makes no sense
since we would have an infinite cost, and infinite fleet.vehicle.cost
records and so on which is not possible.
With this changeset, the expiration will be required if there is a
recurring cost set.
opw-2036071
closes#34883
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Enable "eCommerce Categories" in the website shop customize menu, select
a category, sort by catalog price, filter on an attribute, the category
is lost.
When you sort the records, the url changes from `shop/category/x` to
`shop?category=x`. As the attribute form is a plain get action, the
elements from the query string are lost.
We include the category in an hidden input so it is used by the get.
opw-2032477
closes#34603closesodoo/odoo#34877
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
There was an error in this tax's repartition. A tag was wrongly added to its base.
closesodoo/odoo#34245
Signed-off-by: Josse Colpaert <jco@openerp.com>
Under certain unknown conditions, the range cannot be applied and
triggered an error. In order to allow the user to keep editing, we need
to prevent the dialog from showing, hence the use of `console.error`.
If this error appears, the carret is moved to the beginning of the focused
node.
If this error appears, then bullet can generate an error (I managed to
have the bug once or simulate it by manually breaking the dom and range)
We suspect a wrong snippet custom javascript code.
see: https://github.com/odoo/odoo/pull/34188closesodoo/odoo#34871
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Let's assume a form view with a readonly many2one field with a
default value. When creating a new record, the user can click on
the many2one value, which should open the related record in a form
view (stacked in the breadcrumbs).
Before this rev., this didn't work: we actually came back to the
previous view/action in the breadcrumbs, when trying to open the
related record.
closesodoo/odoo#33172
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
In a graph view in mode 'pie', a matching of dates was
attempted each time a comparison and a grouping of data
using the same date/datetime field was done.
Unfortunately, since the read groups results are ordered using
the order of groupbys, the matching was not sensible in case
the date/datetime field was not the first groupby.
We thus restrict the matching to the sole case where it is
sensible. More work should be done to have sensible matchings
in all situations.
closesodoo/odoo#34379
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The elements style was set globally and thus used to modify
the style of any chart in Odoo after the first loading of a
graph view. For instance, the charts drawn in
sale_subscription_dashboard are not the same before and after
the first loading of a graph view. This is fixed by this
commit.
when image field cannot load an image, it will default to the placeholder image.
If this placeholder image also cannot be loaded it was creating an infinite loop errors
After this commit, we only show one error if the original image cannot be downloaded
and if the placeholder cannot be downloaded, we don't show anything else.
closesodoo/odoo#35226
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Steps to reproduce the bug:
- Create an invoice I
- Set the invoice date in the past and add payment terms
- Validate I
- Create refund from I
Bug:
The invoice date is set as today but the due date was set in the past.
opw:2033438
closesodoo/odoo#34748
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Thibault Delavallée