When buying a kit, the components should not get their unit price on the
kit. By doing this patch + a previous that set the unit_price on the
move as copy False, it'll take the standard price.
When confirming a move for a kit, it is basically unlinked and replaced
by moves for its component. The link to the purchase line was kept in
v10, but since rev[1] it is not anymore. Make an helper to get the
values and override it in purchase_mrp to add the purchase line link.
[1] https://github.com/odoo/odoo/commit/8248f0e153ae5fcc1449d0d05149b61df615ad4f
opw 779497
A return should be valued at the standard price. As the `price_unit`
field is not set as copy=False and a return move is a copy of the
original move, the valuation was wrong.
opw 779803
Only looking on the stock move to determine if a move should create
accounting entries is not enough: it is possible that sublocations
implement some strategies that impact the valuation (example: a move
between stock and stock where the move lines move things to a scrapped
location).
We now look on the move line and if any of the move lines is IN, the move
is IN, if any of the move line is OUT, the move is OUT, if there's a
mix, the move is invalid.
We can imagine a scenario into which the main stock location (wh/stock)
is set as a view location to force people to put things in the
sublocations. Since the stock_account refactoring, only the location of
the stock move is considered to know if the locations should be valued
and, if so, the quantity to value. It is problematic since a view
location shouldn't be valued, but if its move lines put or take things
to or from a valued location to a non valued one, the valuation
mechanism should run.
We now introduce these specifications to handle this kind of usecase
correctly:
- the authority to get the price_unit is on the stock move
- the authority to now how much quantity should be valued is delegated
to the move lines.
The initial condition was too naive, it only checked the presence of
company_id on the concerned locations. This is problematic because
people need to create, for instance, multile inventory loss locations
once they have multiple companies, as the accounts set on the locations
are not property fields.
We also use the same condition to determine if the move is IN or OUT on
the move valuation mechanism and the accounting entries creation
mechanism.
Before this commit, when you had a lead coming from your website form, you
had no informations from where it was located.
It was especially painful for USA which should add customer their location to
know their timezone and know at which time they could call him.
Now, the state code is added to the created lead. It is easy to figure what
timezone the user is on without contacting him first to ask.
This closes#20424
task-29784
When choosing inventory at specific date the default value
is the start time of the server instead of the current time.
When using fields.Datetime.now as default value, will set the function
as default and future object will need to evaluate the funcion each time an
object without default is created. fields.Datetime.now() will evaluate the
function once at the server start and use the retun value as default value
for future objects.
Use case to reproduce:
- Sell 1.1 unit
- Validate the picking with 1 unit
- With or without backorder the initial demand is 0.999
- The backorder initial demand is 0.101
It happens because _compute_quantites uses 'UP' by
default. Since 1.1 - 1.0 equals 0.10000000000000009
we face the problem.
This commit uses an 'HALF-UP' instead. It should not generate
any problem since float_compare in order to decide if we need
a back order or not use a float_round on the same precision_digits
When you have another module installed before sale, and ever changed
some settings, a record of res_config_settings exists and when you
install sale, it cannot set a value for the required new column
'sale_show_tax' for existing records.
To fix this, we have set back the default values on the required field
'sale_show_tax' that has been removed in commit: https://github.com/odoo/odoo/commit/71e5c8b0b5bb10f571030a25875e33b25cda073d
- Delete the tax corresponding to the default 'Sales Tax'
- Access the Accounting settings
Error since record could not be found.
In the case of an `ir.config_parameter` referring to a record ID
(i.e. Many2one), the deletion of this record is not propagated to the
associated `ir.config_parameter`. Therefore, the system tries to access
a deleted record without fallback.
It's not really possible to solve it globally in a stable version, but
we can manually handle these cases by providing a fallback (usually
return `False`).
opw-781864
We do not take CSS seriously enough, but it has an impact on rendering
speed. The rule removed in this commit slowed down the Qunit JS test
suite by a considerable amount:
With a fresh db with no extra addon installed, community version:
- in chrome, before this commit: 103.2s, with this commit: 54.8s
- in firefox, before this commit: 194.9s, with this commit: 117.7s
This is due to the way rendering is done in web browser. They start
checking css rules from the right, so the *:nth-last-child(2) rule was
checked for every element in the dom, each time it was added/modified.
Note that the rule just above (*:first-child) had no noticeable impact,
but I still think that the universal css selector should still be
avoided in general.
The fun part is that I did not find the place where this rule was
supposed to be applied. I assume that it is just a dead rule. If this
is not the case, we can reintroduce the margin-top with the class mt0,
applied on the specific element.
Before this rev., the widget was hidden when the value of its
corresponding field (move_check) was falsy. However, it should
always be visible, regardless its value.
opw 781628
The JournalDashboardGraph requires nv, which is lazyloaded. Before
this rev., a crash occurred when this widget was instantiated and
destroyed before the loading of the lib was complete (because a
function of the lib was called in destroy()).
For instance, press F5 (to ensure that nv isn't already loaded),
activate some throttling in the network tab, go to Accounting and
as soon as the dashboard shows up, click on another menu.
opw 781628
PostgreSQL 10 move sequences' metadata fields into a new `pg_sequence`
system catalog. As a result, selecting from a sequence relation now
only return three fields, and does not include the `increment_by`
metadata field anymore.
This patch obtains the `increment_by` value from the new system catalog
for PostgreSQL server versions >= 10.
Fixes#20269
Before this commit, clicking on 'Go to page' in a page properties dialog would
redirect user to an incorrect link (relative vs absolute) because the link
would not have a leading slash. (We removed it earlier to hide it in the input)
Now, the link is correct
If customer has access to its sale order it should have access to the
linked pickings. It checks customer either has access to the delivery
slip record either has an access token coming from the linked sale
order.
In the view dialog test suite, a few tests created a parent widget, then
created a view dialog, and destroyed the view dialog at the end, but not
the parent widget. As a result, the environment was not properly
restored at the end.
In this case, the test 'SelectCreateDialog correctly evaluates domains'
changed the session (with user_context: {uid: 2}), and this made other
tests crash (web_editor test in particular)
This rev. introduces a new test suite meant to test the webclient
components on mobile devices. The key 'config.device.isMobile' is
forced to true in this test suite, so that mobile specific JS files
are properly executed, which isn't the case in the classic JS test
suite (setting isMobile to true in the test definition is too late,
as the JS files are already processed).
For now, this new test suite contains a single test, which was
skipped until this rev. as it couldn't be executed in the classical
JS test suite.
Both suites are executed at each build of the runbot, and they
can be manually executed from the webclient as well (via the debug
manager).
list_price is the base price of a product which does not include
price_extra.
Note that in the backend the pricelist computation uses
product.price_compute('list_price')
to compute the base price on which to apply the pricelist. For
product.product this seems to be equivalent to the lst_price computed
field.
The original list_price field is unused but has not been removed to
avoid breaking any 3rd party code that is using this field.
opw-781629
The groups were set only on the view which does not prevent abuses.
The fact that users can bypass the groups on the view is not critical as the
changes are logged but this should be improved nevertheless.
In master, proper record rules should be set.
Closes#20427
Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
B which modifies A
In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work
The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields. However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.
Note: the test system had to be adapted to more closely simulate what
actually happens. In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code. This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.
Commit[1] tried to improve the usability of the pick + pack + ship + a
fixed procurement group scenario by erasing the origin value on the
groupped ship that refered wrongly to only the first downstream document
(and in fact refered to multiple).
We forgot the scenario into which we add a sale order line. In this
scenario, we also go through `_assign_picking` and, if an existing open
picking is found, we also wiped its partner and origin value, which was
indeed wrong.
We fix this scenario by being more precise on the erasing condition.
[1] 4a5f07654f
Before this commit, an issue occured when you tried to
create a new record in a editable grouped list view.
A new line was created with an undefined group.
Editable grouped list views are not supported.
So now, we have to switch on the form view when
you click on create. This behavior is already implemented
when you open an existing record.
In 11.0, this part of the code has been removed.
When choosing the shipping address in the cart, if a tax has been mapped
by a fiscal position, the subtotal was not correctly computed.
opw:778405
adapting #20279 to v10
Before this commit, when starting a livechat session as a public user and continuing as a portal user, the livechat crashed
(the poral user couldn't see the channel created before as Admin)
After this commit, the conversation is kept and security insured by the uuid in the cookie
OPW 775568
closes#20281
Simon Lejeune