In march 2017 saas-15 on activity message, the create_uid was displayed
with 26940f8d.
In november 2017 saas-14 an activity was always created sudo() with the
change 53ad585bf.
Thus in saas-15 we always have "planned by Administrator for {user}"
not making sense.
opw-804409
closes#22113
When you create a down payment invoice from an SO, the product that is used in the line is 'Down Payment'.
The description of this product, which is visible for the customer, was not translated to the language
of the customer in the SO and in the invoice. It was translated to the language of the user logged.
This fix is made to keep the same behavior for the description of an SO line and for the description
of the invoice line.
opw:803977
Steps to reproduce the bug:
- Create a bom with lines
- Change on one product in product view form the uom with diffrent category (exemple : unit -> meter)
- Create un manufactoring order : you have an error You try to move a product using a UoM that is
not compatible with the UoM of the product moved. Please use an UoM in the same UoM category.,
the error message doesn't give with product there are an issue. (
if you have hundred of line in your Bom, it is very difficult).
This fix improves the error message.
opw:800328
Before this rev., the default filters were ignored in Discuss. The
SearchView was instantiated and correctly retrieved the default
filters. However, a first manual 'do_search' needs to be done by
the client action for the search view to provide the domain, and
for Discuss to correctly filter the messages.
Steps to reproduce the issue:
- In Discuss (e.g. in Inbox), add to Favorites a given search,
and tick 'Use by default'
- Leave Discuss, and then go back: the default filter correctly
appears in the search view, but the messages aren't filtered.
Before this commit, the special mrp validate_move method did a call to
quants_move with an incomplete signature. IN the use case, that we want
to make "own" produced quantities by a third party (maquila), we can do so in
downstream modules by restrict the partner on the move so that any moved (or
created) quants will belong to this partner (owner). This is certainly
important for the case where finished products are not your own
property. Courtesy of blaggacao.
Closes#21072
Before this commit, the triangular case was not handled:
A transaction in dropshipping which happens outside our country
(provider and customer both outside our country)
was counted in the intrastat XML when it shouldn't
After this commit, those transaction are not accounted for in the XML
opw-800342
Steps to reproduce the bug:
- Create a new RFQ
- When it's in draft state, log an internal note using the 'mail.compose.message' dialog.
Bug:
- RFQ is now in 'sent' state.
The fix allows to inherit from mail_purchase_order_on_send method to change the base behavior.
opw:801549
To keep the same behavior as in 11.0, you can only add a purchase order to a vendor
bill when the vendor bill is in draft. Afterwards it is not longer possible.
opw:803068
Add the inventory value in the pivot view. Indeed, the Unit Cost
displayed is the cost of the quant, which is not what is expected in
case of standard costing method.
opw-785872
Before this commit, all tooltip users was showing website and parent_name from
the Main company and not the current focsed partner.
This commits closes#18430
@kangol: fwd-port company_name
If you set 200 kamra to allow to flag a post and 300 to edit all post, you was
not able to flag the post before this commit.
This commit closes#21274
@kangol: warning, fwd port need to add tag_ids into trusted_keys
The report 'Leaves by Department' only counts full days-off, instead of
taking into account the actual number of days.
This commit fixes the total number of days per employee. However, there
is still a limitation on the display: a day is either fully colored or
not at all.
opw-801061
Before this commit, in the event that the admin user has set the language
to english, but the COA's target company had a different language,
the admin user's language had been taken instead of the copany's one
for the translation of journals and other coa intialization stuff.
This is wrong as the CoA is more connected to the company, than to the
user, which could be a functional support user that just happens to prefer
the english version over the local one.
Now, we ensure in two neuralgic places, that the company's language is passed
to the context and therefore picked up by the translation's GetTextAlias.
Signed-off-by: David Arnold <dar@xoe.solutions>
When there are too many labels to display on the x-axis, they overlap
and it simply becomes unreadable. By slightly rotating them, this can be
avoided in most cases.
Back-port of this commit 388e258ce8
opw:802925
Routes created when creating companie were not set to the correct company.
Steps to reproduce:
- Go to Settings > General settings: Activate Manage Multiple companies.
- Go in Inventory > Configuration>Settings: Click "Manage several Warehouses,
each one composed by several stock location". Click "Advanced routing
of products using rules".
- Go in Settings > Users > Companies: Create new companie "ThisNewCompanie"
- Go in Inventory > Configuration>Routes: Open Routes named ThisNewCompanie.
Bug:
All the routes created automatically by creating the company "ThisNewCompanie" are
not set to the company "ThisNewCompanie". They are set to the company of the logged
user when "ThisNewCompanie" was created
opw:787229
Purpose
=======
When you create a budget, the field analytic account on the budget line is not mandatory but if you don't set one, it doesn't work, the practical amount always stays at 0 even if there are journal items in the accounts defined in the budgetary positions
The field `price_subtotal_signed` contains the price converted in the
company currency. However, we should make sure to use the exchange rate
of the invoice date for its computation.
An use problematic use case is the creation of a deferred revenue from
an invoice (commit 7fe89d08b3).
opw-702352
As admin every tax is loaded, which is wrong anyway.
When the admin opens a session a change the cashier in the POS interface,
every order is made with every tax ever (on the product)
which could lead to major faulty records
See the case on OPW 786803 which is critical
[FIX] mail: delete leftover followers
Previous to this commit, if during the unlink of a model which inherits
from mail.thread an exception is raised before mail.thread's unlink() is
called, followers for such model won't be properly deleted from the
database.
This commit changes this by overriding ir_model's unlink and deleting any
followers whose res_model is not installed.
Partial back-port of 3614193Fixes#21462
OPW 786790
Before this revision,
Assigning a user for which its partner is inactive
was sending the assignation notification email to the `partner_id`
of the object.
e.g. Assigning a task to a user for which its partner is disabled
sent the assignation notification email to the customer of the task.
opw-787659
Discarding a new record triggers the 'history_back' action. This makes
sense if the record was discarded from a normal form view, but not so
much when in a modal, where the expected behaviour is to close the
dialog.
This commit overrides the function in the action manager which handles
the switch to the previous view. It checks whether a dialog window is
open, in which case it simply closes it.
note: 10.0 backport from 11.0 33aa89edcloses#20405
opw-786866
closes#21792
When a user was closing a POS to go into the backend, and click on "Reprendre",
there was an error which prevent him to reopen the POS.
There was a confusion between object <datetime> and <datetime.datetime>, as
the previous code was trying to use the function timedelta() from datetime.datetime
instead of datetime. As a result, the error states that datetime.datetime has no
function timedelta.
opw-801523
- Activate Work Orders
- Go in MRP > Reporting > Work Orders
The status filters ('Ready', 'Pending'...) do not work.
This is because the action forces the domain to `[('state','=','done')]`
instead of using one of the available filters.
opw-788043
The stock_history view is generated from by grouping of move from
sources and move to destinations which depending on the request and
number of request can be rather slow.
This fix replace a possibly high number of request by a slower number.
On a production instance, doing an inventory at a choosen date:
- with 300 stock moves, went from 4 minutes to 4 seconds,
- with 130 000 stock moves, went from 66 minutes to 10 minutes
opw-765793
closes#19594
The web planner specified no language for frontend so the website
planner on the frontend was never translated.
This commit add a specialized fallback for this use case so the planner
on the website is in the language of the current user.
The code is the same that get_context from web_editor.base but requiring
that would possibly adds delays (for dom_ready) that we don't want.
note: this is for 9.0 up to not including 11.0, in 11.0 another solution
is used and in master a bigger change is being worked on.
opw-781727
fixes#20829closes#21004
Before this commit, one could choose the App Switcher as his Home action.
and arriving on /web would trigger an infinite loop at startup
After this commit it is not possible to choose the App Switcher as Home action anymore
OPW 800323
Commit 74e4130f5f makes sure to make the accounting date prevail on
the invoice date when it comes to currency conversion.
However, the choice of date is not universally recognized. Softwares
(and accountants) might use either the accounting date or the invoice
date.
Therefore, we provide a hook se the behavior of the software can easily
be changed if necessary.
opw-783372
When an user goes to its cart and removes all the items, the checkout
button is hidden so that the user cannot start an order with no product.
This behavior was not working in languages which are not the default
language of the website, as the button was found in JS relying on the
fact it started by "/shop/checkout", while it can be something like
"/fr_FR/shop/checkout".
Closes https://github.com/odoo/odoo/issues/21722
When the unit price of a kit is computed in anglo saxon accounting, the
average price of kit parts is not multiplied by the quantity of this
parts in the bom.
E.g.: a kit of 2 prod1 and 1 prod2, when the price is computed, it only
take into account the cost of 1 prod1 and 1 prod2 to compute the kit
cost instead of 2 prod1 and 1 prod2
opw-786268
Christophe Simonis