Steps to reproduce the bug:
- Set a multi company environment with two company A and B
- Set user admin in company A
- Set user demo in company B
- Create a PO with user demo
- Send a RFQ
Bug:
The company of the admin user was displayed in the footer of the email.
The function _notify called on res.parter model is called in sudo by
the function _notify on mail.message model.
The function render_template on mail.template model uses the user defined
on self.env to render the template. So the user admin was always used.
opw:1835647
Before this commit, when uploading a file as attachment in Safari,
The file icon kept on showing 'downloading' whereas the request was successful
This was because the return from the server had a different UTF-8 norm than Safari
After this commit, it works well
OPW 1836545
closes#24307
Assume a list view with a many2many field, and a record for which
that many2many contains a single value, whose nameget returns the
empty string (which is a falsy value in JS). Before this rev., it
triggered an infinite number of namegets, and the browser crashed.
It was because the cell was re-rendered when the nameget returned,
and in the rendering of the cell, it re-performed a nameget if
the value was falsy.
opw 1838255d
In V11 with automatic invoicing set in website settings, it's no longer
possible to confirm an online order paid with wire transfer without
registering the payment. A user might want to confirm the order and then
register the payment.
Deactivates the `Mark As Paid` button on the order. (by removing the
xpath)
Task #1819491Closes#24347
and keep all those filters at last. (PR#20463)
e.g. If field used in color attribute of calendar view does not have value then such sidebar filters will not have string besides filter checkbox
in such cases we should set Undefined string and put all those filters at last in filter list
Currently we can see issue in calendar of manufacturing orders in db with demo data
Related to Issue #1778360
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Scenario : Create a transfer on a product tracking by lot. Update the
operation type "Receipt" by unchecking the "show reserved" option.
Open the Register lots, pack, location wizard and set some lots with a
quantity done. The quantity done field is not updated in real time.
Issue :
The depends function on quantity_done is triggered only on move_line_ids
but "show reserverd" option replace move_line_ids by
move_line_nosuggest_ids in the wizard.
Transifex URLs have an original scheme using #lang, followed by the module or
'$' (for any module) and the searched text can be quoted
Before this commit the link was cut after
https://www.transifex.com/odoo/odoo-11/translate/#fr/, making the link not
clicable
Closes#24346
It was possible to edit a leave request in order to use a leave type
which had no more days left. This was due to a missing field in the
constrains call.
Closes#24320
There's a certain configuration of UOM that is not correctly handled in
the v11 stock:
- create a move with an UOM having an higher factor than the product's
UOM
- this higher UOM has a rounding of 1.0, meaning it doesn't allow
partial reservation
- use the product's uom in this move and enter quantities that aren't
expressible in the move's uom
A practical example is to set the rounding of dozen at 1.0, set the uom
of a product to units, create a move for a dozen and create a new move
line with 8 units.
The first issue is the `quantity_done` field, that uses an half-up
rounding on the `qty_done` field of each move line and sum them. When
applying this logic to the previous example, `quantity_done` field would
be 1.0, meaning we won't make a backorder for the missing 4 units. We
fix these issue by summing a non rounded qty_done and afterwards
rounding this value to the general products'UOM. This mean
`quantity_done` is technically not be expressible in the move's uom, but
keeping this value close to the reality will allow to handle the
backorders and extra moves correctly.
The second issue is that the backorder is always expressed in the move's
uom. In the previous example, this would mean creating a backorder of 0
dozen. In v10, an error was throwed, saying this operation is
impossible.
The `_prepare_move_split_vals` previously always received the quantity
of the backordered move in the uom of the original move. This is a
remnant of the v10 implementation where, if the quantity to backorder is
not expressible in the original move's UOM, an error was throwed. We now
pass the used uom via a context key to not update the method signature,
as it is probably legitimately overidden by custom modules. This way, in
the previous example, a backorder of 4 units is created.
The last issue is in `_action_assign`. Let's say you have 8 units in
stock and you want to reserve a dozen, the system will reserve 8 units
and then convert back 8 units in dozen, meaning a dozen was reserved.
This resulted in awkward situation where more items than available were
reserved, and the famous "cannot unreserve more than what's available in
stock" was throwed at almost each operation. To solve this, we convert
the not-yet reserved quantities back and forth in both uom. This
prevents partial reservation when not allowed, which is good. We had to
adapt some lines of `_action_assgn` that expected
`_update_reserved_quantity` always at least partially reserved the move.
It is now possible that it doesn't reserve anything.
We also normalize the quantity with a greater decimal precision when
deciding if we open the immediate transfer wizard or not (in the
original exemple, if you enter a single unit the immediate transfer
wizard would be openned because 0 was done in the UOM of the dozen). We
also prevent to enter `qty_done` on the move line if the value doesn't
honour the rounding of the UOM.
We introduce two tests, a simple `_action_assign` in MTS and a more
complete MTO scenario with backorders, extra moves and invalid qty_done.
opw-1835186
opw-1835946
Restore behaviour of not adding the separating dot if the module field
of an ir.model.data record is empty. This is useful/important for
interop with external systems.
When a record fields are prefetched, the currently accessed record is
prefetched as well as PREFETCH_MAX (=1000) minus currenly accessed
records.
Since 439fa826 the id field was thought as "prefetched" but was not,
which caused that in an onchange, we would have a prefetching as follow
for 1200 records:
- get records 1-1000
- get record 1001 (1001-1200 INTERSECTION 1-999 (id) + 1001 (current))
- get record 1002 (1002-1200 INTERSECTION 1-999 (id) + 1002 (current))
- get record 1003 (1003-1200 INTERSECTION 1-999 (id) + 1003 (current))
- ...
- get record 1200 (1200 INTERSECTION 1-999 (id) + 1200 (current))
So we would do 201 queries instead of 2 when prefetching the records.
The added test without this change failed the query count with:
"AssertionError: 284 not less than or equal to 5 : admin"
opw-1837548
opw-1837552
closes#24326
- Create a stockable Product A
- Get create an incoming picking at date D for A
- Go to Inventory > Report > Inventory, and search for the the inventory
at date D-1.
- A should appear with a quantity on hand of 0.
- Filter on 'Available Products'
The product still appear in the list with a quantity on hand of zero.
The optimized method `_search_qty_available_new` is used, although it
doesn't take into account dates.
The original use case for this optimized method was to quickly get
products with stock on hand, i.e. products with quants without needed
information of stock moves.
opw-1833510
- Create a MO for Product A with quantity to produce of 2
- Produce 1
- Open the associated BOM, and add a line to the bom
- Go back to the MO and try to update the qty to produce to 1
Traceback: division by 0
opw-1838006
The portal view for tasks previously listed all task of all projects
without grouping them. It was a problem, mainly when we want to make
the distinction on project label_tasks, to make the difference
between tasks, issues, ... Grouping task by project by default allows
to show the label_tasks before each project.
Grouping the tasks removes the possibility to define a primary
ordering. We want to be able to ungroup the tasks in some cases.
The implentation was done in the portalsearch bar adding
a group by option. The portal proposes two grouping options,
project (by default) and none (to keep strict ordering).
Task: #1827950
PR #23769
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
Currently, the default field widget of type html is not defined in the
web addon, but in the web_editor addon. It uses the summernote library
and different assets.
The web_editor addon is defined with auto_install=true, so it is usually
not an issue. However, it could happen that there is some issue with
the web_editor asset bundles. In that case, any form view with a field
of type html will crash.
With this commit, we define a default widget of type html in the web
addon. This will render as text (so, not exactly what one might
expect), but it is still better than making the web client unusable.
Assume a custom field F is defined on model 'res.partner'. The setup of F may
silently fail because of missing stuff. In that situation, setting up the
field inherited from F on model 'res.users' should also silently fail.
To reproduce the bug, install Invoicing, create a related custom field F on
'res.partner' with 'property_account_position_id.active', and install another
module. Setting up F after loading module 'base' will fail because the field
'property_account_position_id' does not exist yet. The error is not caught by
the inheritance of F on model 'res.users', and the installation crashes.
When calculating the stock_value of a product,
the system will take into account all the locations
that have this company as company. (that way if owner_id
is not set, the company_id on the location is the owner (virtual: not set))
The Qty on Hand field takes into account however
the quantities that are in the warehouses.
This could lead to weird situations where the Quantity On Hand is 0
and so the record is not shown, while the stock value is positive.
(e.g. stock in Transit)
In order to use the same logic for both fields, we pass company_owned=True
in the context.
Assume a custom field F is defined on model 'res.partner'. The setup of F may
silently fail because of missing stuff. In that situation, setting up the
field inherited from F on model 'res.users' should also silently fail.
To reproduce the bug, install Invoicing, create a related custom field F on
'res.partner' with 'property_account_position_id.active', and install another
module. Setting up F after loading module 'base' will fail because the field
'property_account_position_id' does not exist yet. The error is not caught by
the inheritance of F on model 'res.users', and the installation crashes.
OPW 1835872
- Fix an issue where the transaction were always set a 'form_save' thus always creating payment tokens.
- Fix an issue where when the customer paying while not being logged in was crashing.
The issue is due to the fact that we are creating payment transactions linked to no partners, doing so it crashing the code when creating the payment token with no partner set.
The Arabic we use on Transifex is "simple" Arabic, not the one from Syria.
The .po files we synchronise are named 'ar.po', not 'ar_SY.po'
Change the iso_code to match the one we actually use.
transifex module relies on the iso_code to make its URL
The issue occurs when `read_group` is called with a date/datetime field to
group and order on, and the group_by is qualified, such as:
model.read_group(..., groupby=['date:week'], orderby='date')
The ORDER BY clause in the query should use the same term as the GROUP BY
clause for the corresponding field.
OPW 1834148
When working with relational fields, the sorting function would
compare empty recordsets with Strings (the field value),
crashing in the process.
This is essentially an addendum to previous commit
b6c962e62a
which fixed the sorting for non-relational fields.
opw 1831457
If a user only has the stock user access rights, he's not able to
validate or write on a move that has to update the delivered quantities.
Closes#23782
opw-1835138
The check on the event target and the barcode target is done outside
the check on barcode found. That result in a warning for each modal/form
view that is pending.
This commit do the check before doing any operations in order
to directly stop if the event target is not similiar to listening
barcode target
The barcode scanner and the quantity listener do not use
the same proccess although they act for the same operation.
(For example the quantity listener trigger onchange server side
while the barcode scanner not if 'notifychange' key on the
active_barcode is set to False)
Since quantity listener is based on candidate we could directly
call the _barcodeSelectedCandidate method in order to have a common
behavior and code.
Goffin Simon