This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
- Set your company to USD
- Create an expense in EUR:
Amount: 100
Tax: 15% Excluded
- Validate, post the journal entries
It crashes because of a missing `.id`, but on top of that... not a
single AML is correct.
opw-1938570
closesodoo/odoo#30987
In following configuration:
- We have two companies: A and B
- We have a shared product X
- We set a BOM of type KIT for this product X for company B only (the field company on a BOM is mandatory)
- We set no BOM for product X for company A because in company A we sell the product as a regular product
When we sell product X in company A, as a normal stockable product, the invoicing behavior is the same as
when we would sell KIT products. This is because we don't check the SO company when searching the associated
BOM.
closesodoo/odoo#30927
Commit bfb0f1e2a5
did a very good job not seeing that the lines only used move[0],
and called move.field directly.
This could result, for certain BoMs, in traceback.
opw 1928677
closesodoo/odoo#30938
When dropping a snippet into a page, it is dropped in the drop-zone
which is the nearest of the user cursor. When moving a snippet, that
condition did not apply and the user was required to put the cursor at
the exact location of the drop-zone.
Also, for both drag and drop features, the drop zones which appeared
were not displayed correctly for full width columns, which made dropping
sometimes impossible when multiple col-*-12 were below each other.
task-1937758
closesodoo/odoo#30899
If fleet.vehicle_state_active is not found in the system then the method
will raise an error, hence it won't allow creating any fleet.vehicle
closesodoo/odoo#30925
Backport of d9fed5381a78c19ce14ddc8b9233f60d53c65453
Before this commit, when opening the calendar view with a specific locale
in the "week" view
the days were translated but the date format was wrong and fell back to english
This was because the translated terms were passed explicitly, but the locale did not
get passed
After this commit, we do what it takes to pass the locale to fullcalendar
and the dates are formatted with the right pattern
Also, there may be a bug in fullcalendar, because just passing the locale in the options
won't work, it should be instanciated first in fullcalendar's "locales cache"
OPW 1922092
OPW 1934127
closesodoo/odoo#30909
Usecase to reproduce:
- Create a route with a warehouse_ids
- Uncheck warehouse_selectable on route
- Create a picking that use the route
It should fail since the route is not applicable.
It happens because _search_rule only check for route with warehouse_ids
but it do not check for warehouse_selectable. We can't fix _search_rule
since stock_warehouse.py creates multi step delivery and reception
routes without warehouse_selectable thus it would break existing configuration.
Instead create an onchange on warehouse_selectable that remove
warehouse_ids on route.
partial backport of commit a35df8d371closesodoo/odoo#30844
In the e-comerce, when the user try to add a new card in this payment
methods.
Before this commit, to validate the card, besides of the creation of the
payment token, an amount of $1.5 id charged and refunded.
During the refunded an error was raised. This error arrives because:
payments made via Authorize.net are settled and allowed to be refunded
only on the next day.
https://account.authorize.net/help/Miscellaneous/FAQ/Frequently_Asked_Questions.htm#Refund
<quote>The original transaction that you wish to refund must have a status of Settled Successfully.
You cannot issue refunds against unsettled, voided, declined or errored transactions.</quote>
This means, we can't refund directly after the payment.
Now, we only create the payment token. As Authorize.net verify the card
during the creation of the token, a new verification is not needed.
OPW-1927754
closesodoo/odoo#30905
- Create a product and set a contact as the vendor (for instance, Arthur
Gomez from Asustek in the runbot)
- Set a specific name and code for the supplier
- Create a RFQ for this vendor (Arthur Gomez - the contact person)
- Add the product, confirm the RFQ
On the product, the company (Asustek) is automatically added as vendor,
but there is no vendor name and code.
opw-1929745
closesodoo/odoo#30891
Have a partner in French while you operate in English
Click on 'send by email' on a invoice/sale order/purchase order
Before this commit:
- The body of the mail is translated in the partner's language
- but the notification header/footer surrounding the body was not
This is because:
- mail templates apply to a model
- in the case of the notification header/footer, this model is 'mail.message'
- mail.message doesn't have a lang field
- at the notification rendering time, we don't have easy (and generic) access
to the "real" model or to the lang (let alone to which lang to apply) that we need
After this commit, the notification is translated but:
the lang to get is hardcoded, and is the one on the partner of the inv/so/po
and is un-coupled from the dynamic lang on the proper inv/so/po template
This patch is hackish at several levels, I suggest that a generic solution is found in master
If no other solution is found until then, then the patch may be forward-ported
OPW 1935091
closesodoo/odoo#30873
- Activate:
'Track lots or serial numbers'
'Manage several Warehouses, each one composed by several stock locations'
'Advanced routing of products using rules'
- In the main warehouse, activate Pick + Ship
- In Stock Locations, create 'WH/Stock/Shelf 3' and 'WH/Stock/Shelf 4'
(1 and 2 already exist, use the same config)
- Create a new product 'Foo', activate Tracking By Lots
- On Foo, use 4 times the "Update Qty on Hand" (order is important):
Add 1 on Shelf 2, create a lot
Add 1 on Shelf 1, use the same lot
Add 3 on Shelf 4, use the same lot
Add 1 on Shelf 3, use the same lot
- Create a SO, set a partner
- Ensure that YourCompany is used as warehouse
- Add several SO lines (order is important)
a line with 1 product Foo
a second line with 1 product Foo
a third line with 4 products Foo
- Confirm the SO, you now have 2 deliveries, 1 Pick, 1 Out
- Open the Pick, all moves should be available, you should have:
4 operations:
Shelf 2, quantity 1
Shelf 4, quantity 3
Shelf 1, quantity 1
Shelf 3, quantity 1
3 moves:
A, quantity 1
B, quantity 1
C, quantity 4
- On each operation, select the lot created before and set the quantity
to be fully done
- Validate the Pick
The moves end up like this:
- Move A with qty 1: is done and linked with a quant of 1
- Move B with qty 1: is done and linked with no quant
- Move C with qty 4: is done and linked with a quant of 1, a quant of 3,
a quant of 1 (sum is 5)
In the Out picking, the move linked with the source move (B) with no
quant stays in "Waiting another move" even if the source move is done.
This outgoing move will never be available.
In the method `recompute_remaining_qty`, we loop on operations, and
match them wih the moves. However, the operation with the largest
quantity (Shelf 4, quantity 3) is processed before the move with the
highest quantity (C, quantity 4). Therefore, when we later loop on move
C, `qty_assign_cmp` is larger than zero, which sets `need_rereserve` and
ultimately triggers `rereserve_quants` in `do_transfer`.
A first part of the fix is to check for the location of the quants when
matching moves and operations. This fixes the original issue, but
inconsistencies can still arise since a quant which is taken partially.
therefore, we make sure to never take more than the quantity on the
link.
opw-1932624
closesodoo/odoo#30857
- Set a cost of 12.34 for product P
- Create manually a new analytic entry
- Choose product P
- Set desired quantity
The analytic amount is set to 12.00.
This is because `move_id` is empty, therefore `currency_id` is empty as
well and `decimal_places` is zero
opw-1924184
closesodoo/odoo#30869
Before this commit, the customer is allowed to change picking type after the
stock.picking record is moved from draft.
But it doesn't make the changes in the stock moves and operations as the
procurements are already created for initial demand.
To avoid confusing the user, it can now only be modified in draft state.
Authored by SodexisTeam
opw 1848252
opw-1934814
closesodoo/odoo#30865
Activate multi-company, deactivate the common contact book.
Create a PO P with user U1 in company A. Switch to company B.
User U2 in company A tries to send P by email.
Rendering of the template fails, because it tries to access object.create_uid,
which breaks multi-company record rules.
The signature was not working because it used user_id, a non-existing field,
instead of create_uid.
opw 1930521
closesodoo/odoo#30868
In stock.picking, in mode show detailed operation, add a product with
unique serial number tracking.
Before this commit, a warning about the qty is raised. This warning,
must be raised only if the qty is different from 1.
However this is not the case,
the warning is raised at each modification of the line.
This issue occurs since the rounding given to the float_compare is 0.0,
because self.move_id.product_id is not set.
Float_compare with a 0.0 rounding always return different, hence the bug.
Now, the warning is only raised when the qty is different from 1.
OPW-1932044
OPW-1931378
closesodoo/odoo#30651closesodoo/odoo#30851
Previously, it was only possible to make a return in
- the location the move was coming
- a return location that is child of the parent_location, actually
meaning a return location in the warehouse
This commit now allows making return in all return location, even one
located in another warehouses.
closesodoo/odoo#30836
- Create a SO with 2 lines of the same product (set route as Drop Ship)
- At validation, both lines are merged into a single line in the PO
As a result, one SO line will be over-delivered, and the other
under-delivered.
Two lines should be kept in the PO.
opw-1928702
closesodoo/odoo#30800
- Create a product P with:
Costing Method Average Price
Inventory Valuation Perpetual (automated)
- Create a component C with, costing 10.
- Create a BOM for P:
1 Unit of C
- Create a MO for P, validate
=> a journal entry of 10 is created
- Modify the BOM for P:
2 Units of C
- Create a MO for P, validate
=> a journal entry of 15 is created
The journal entry should be 20.
opw-1928342
closesodoo/odoo#30766
Create a tax of type "group of taxes".
Put taxes in its children_tax_ids field.
Change the type to something else.
The view hides the field children_tax_ids, since it doesn't make sense anymore.
However it doesn't actually remove the children_tax_ids.
As a result the child taxes are use in the computation.
We add on onchange to avoid that unfortunate situation.
opw 1931089
closesodoo/odoo#30727
Through many design refactorings, the community caret position was
broken while the enterprise was not. This commit removes the breaking
rule to put it in enterprise only.
closesodoo/odoo#30799
Have a sales team with one or more orders to invoice.
Open the 'Sales Channels' report in Sales.
Before this commit, the 'Invoicing' progress bar of the report,
showed the number of order to invoice and not the sum of the
invoicing amount.
Now, the 'Invoicing' progress bar of the report shown the sum of the
invoicing amount; and the number of order to invoice are shown in their
own field.
OPW-1922438
closesodoo/odoo#30735
Before that, having a payment with amount_residual=0, but amount_residual_currency!=0 did not display it.
Also, 'outstanding credits/debits' label was displayed in case amount_residual was != 0 with an amount_currency=0 (and of course, a currency_id value was set on the aml). This could for example happen in case of partial reconciliation, were the amount_residual field is used to keep track of what will have to be written in the exchange rate difference entry when the reconciliation becomes full.
closesodoo/odoo#30362
- Set the OS in a timezone such as the current day is different from the
day in UTC (e.g. America/Nome before 10:00 AM or Australia/Melbourne
after 3:00 PM)
- Open any datepicker
- The 'little triangle' indicating the current day is wrongly set (one
day before or after)
Knowing that Odoo always creates momentjs date and datetime with the
`UTC` flag set to `true`, the `bootstrap-datetimepicker` does something
which seems inconsistent.
First, it retrieves the `viewDate`, and sets it to the beginning of the
month and week in:
https://github.com/odoo/odoo/blob/1c6c504215f3ef09e6336c92c9d350e87599eaa1/addons/web/static/lib/bootstrap-datetimepicker/src/js/bootstrap-datetimepicker.js#L725
In this part, it is important to note that each `startOf` functions
called sets the hours/minutes/seconds to zero. It means that the
reference time is changed.
Then, it iterates on this newly created date, and determines `today` by
comparing it to `getMoment()` in:
https://github.com/odoo/odoo/blob/1c6c504215f3ef09e6336c92c9d350e87599eaa1/addons/web/static/lib/bootstrap-datetimepicker/src/js/bootstrap-datetimepicker.js#L748
However, `getMoment()` returns the current date and time, but with the
`UTC` flag set to `false`.
Therefore, we compare a UTC datetime on which the reference time has
been changed to a non-UTC datetime, which fails to give the appropriate
current day.
There are two approaches to solve this. The first possibility is to
change the way Odoo defines momentjs dates and datetimes, maybe by
removing the `UTC` flag at creation. This sounds like a bad idea, since
other widgets or views (such as the calendar or the pivot view) make use
of them. This is likely to introduce a bunch of new issues with TZ in
these views. The second approach is patching the library to fit our use.
Although we usually don't do such a thing, this allows to specifically
solve this use case, and in particular placing the 'small triangle' at
the appropriate date without impacting any other part of the system or
the library. It can be easily performed by comparing the dates and the
months to make it work.
opw-1915251
closesodoo/odoo#30538
When printing multiple reports with the "Reload from Attachment" option
selected, the order of the rendered pdfs was not respected. Using an
ordered dictionary instead of a randomized one solves the problem.
opw 1915685
closesodoo/odoo#30690
This commit simplifies the code and improves the performance
of _compute_sale_order_count.
execution time from O(n^2) to pretty close to O(n)
Project : Performance Issues
Task : Geostaff : Success Pack 5 (100h) (opw-1912303)
With https://github.com/odoo/odoo/commit/ac8b0fcfc5299b5ea62543b8382cb419fed4868e,
the 'country_events' class was renamed to 'oe_country_events'. This was
done correctly for JS animations and snippets but not for the 'Country
Events' option in the customize menu. This made the option useless.
This commit solves the problem by supporting the two classes (as it
is a stable fix).
closesodoo/odoo#30662
Lucas Perais (lpe)