The idea is to do like the sale report: being
able for other modules to extend the report and
add their own fields. As we are going to split
stock from purchase, we will need this.
Revision on 8ac98fc78a
The commit above does not check whether the list contains data or not.
As a result, if there are no data in the list, there is no reason to
fetch `name_gets`.
In fact, there could be a traceback because some parameters of this rpc
are computed from data in the list. So if there are no data in the list,
the parameters of the rpc are undefined. This was the case for a test
in enterprise.
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
When seeing the work orders view, it would display an empty black box instead of
the proper message.
The message is not displaed since creation is deactivated.
opw 1839001
Have a delivery for a client, with pack operations
Connect on this user's portal
Go on the SO and then on the delivery
Before this commit, there was an Error 500
because access to fields of pack_operations was forbidden
After this commit, the report downloads well
OPW 1849520
closes#24849
datetime.date(year, month, day).weekday() is undefined for year > 9999.
When creating a google recurrent event that is set to never end,
Odoo tries to create 100 individual events.
If in Google calendar the user sets a recurring event to a custom interval,
of say a century, then the hundredth event is in 100x100 years, so in 12018.
Since 12018 > 9999, we get a traceback and synchronisation never happens.
opw 1845311
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
When we perform a planned transfer (which is the default behaviour now)
we are not able to set a quantity done on move lines in a confirmed
move because, the field 'is_initial_demand_editable' is true but should
not.
To fix this, we set 'is_initial_demand_editable' to true when it is not
a planned transfer AND the state of the move is draft, which is the
desired behaviour.
This behaviour come from rev:https://github.com/odoo/odoo/commit/ffb79761c1225c8a9c9303db4781f1b40b5d9944
When a picking is returned, the scheduled date stay unchanged. This date can be
in the past if the return is made at least one day after the transfer. This commit
set the return day as scheduled date
When a picking is in 'Done' state, we add the effective date on the form in
addition to the effective date. The user can know the date when the picking was effectively
made.
Starting with the 1000th user, the kanban view returns the id value
as '1,001', which, for some reason, does not go well when trying to
find the attachment by url...
Use `raw_value` instead, which does not format the id value.
Depending on the situation, it is possible to have move with origines
and destinations that have a loop.
A simple example is a return of a return, the origin and destination of
the return of a return is the return itself.
opw-1845444
closes#24787
Purpose is to avoid mixing various data types in the same generic mail_data
file. We already have 2 crons and the upcoming moderation feature will add
some more. Let us put them in their file to ease the finding.
This commit is linked to task ID 29521.
This commit provides a test suite for sale flow and unit tests.
We split tests in different files to try regrouping them by
testing purpose:
1/ test_access_rights.py checks employee, sale person, sale manager
and portal access rights. It is executes in post-install mode to be
sure other addons does not break the security rules.
2/ test_onchange.py checks the onchange using the SFF mecanism in
order to simulate what a sale person really does in its day-to-day
job.
3/ test_sale_pricelist.py execute a sale flow with different pricelist,
as this is a delicate aspect.
4/ test_sale_to_invoice.py contains tests about refund, discount and
downpayment, as none of those were tested.
Task #43928
As 'invoice_ids' on sale.order is a computed field, creating
a refund should invalidate this field as 'invoice_ids'
should contain invoices, refunds, ...
When using the refund wizard, the credit note will be linked
to the SO lines (see `_refund_cleanup_lines` override in sale).
Without the new trigger, invoice_ids will not be recomputed, and
executing 'sale_order.invoice_ids[1]' will not return the refund
account.invoice.
This commit fixes it.
`currency_id` variable is a recordset, so stop browsing it again !
In the meantime, if those variable had a meaningfull name, this
error would never occured !
Coming from 7a282c9965
Without this commit, reading all fields of sales
order will raise an access error if user does not
have access to hr.expense documents. An since
the expense count is displayed on the form view, this
can be annoying.
This commit makes the computation of the expense
count done by 'sudo', as there is not critical
informations at stake.
In some case, (e.g.: demo data), datas_fname is undefined and match of
undefined will crash and block the modal to be opened.
Uncaught TypeError: r.datas_fname.match is not a function
Set the right employee's possible states.
Before the restyling, the main title was always “Welcome!” regardless
of the user state (checked_in or checked_out). Using conditional titles
has exposed the issue.
Before that, the following scenario (tested in purchase/tests/test_anglosaxon_valuation_reconciliation.py) failed:
- create a PO
- change of currency rate
- create and validate vendor bill in foreign currency
- receive goods
- change of currency rate
- return the goods
- change of currency rate
- refund the bill
At the end of it, both invoices (bill and refund) were not in 'paid' state, but they should have been! The anglosaxon stock valuation code had some issues in the way it managed currency rates. The main one was that we converted the computed valuation_price_unit variable in company currency using the date of the invoice as a reference, which was wrong in case the invoice was a refund, as it should then use the date of the valuation for this. This problem caused the code to detect an exchange rate difference between refund and valuation as a price difference, hence generating a line in the price difference account, which caused the debtor account line of the associated account.move to be wrong, and hence impacted the residual field of the invoice ("amount due", in GUI). Finally, as this field contained an inconsistent value, the refund invoice was not marked as paid after reconciling it with the original one.
Solving this needed to refactor the code quite a bit, so that we don't convert everything in invoice currency in the end, but rather do it directly everytime we compute a part of valuation_price_unit. The test had also to be partly re-written as it was too naive in the way it used currency rates, we needed something closer to a real utilisation of the program.
- Create a Finished Product tracked by SN
- Add a BoM with routing (in several steps) to that product: component A
should be consumed in 1st step and component B in 2nd step
- Create a MO, plan it, go on the first WO and produce the finished
product with SN 0001
- Then go on the second WO and produce the finished product with SN 0002
- Back on your MO, you'll see that
Finished Product = SN 0002
Component A has been consumed for SN 0001
Component B has been consumed for SN 0002
- Mark the MO as done
No blocking error is raised so I'm consuming a product for a finished
product I'm not really producing. Traceability report will be wrong too.
We raise a blocking error to avoid this use case.
opw-1832098
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
The subtask_project_id field was removed by task #38498, amongst many
other changes.
This change makes some workflows much more difficult: for example, using
a different project with its own columns is kind of awkward. It
requires many more clicks and custom filters to achieve the same result
as previously.
With this commit, we simply reintroduce the field and use it to set the
default project_id of a subtask.
Mercury can partially approve transactions in case a card does not
have enough credit available to cover the full amount.
Before this the payment amount was kept as the full purchase amount
leading to a difference between what Mercury charged and what Odoo
registered as charged.
opw-1840946
Before this commit, some records in a list did not show the name of their
many2one fields.
This case occurs when the records in the list are created from a default_get,
and the records do not fit in a single page. In that case, the records in the
first page correctly display the names of their many2one fields, but not the
records in the other pages.
Fixes#24547
Before this commit, when a list contains records with many2one fields that
contain the same values, duplicate ids were passed to the server on rpc
`name_get`.
For instance, if 40 records in a list refer to a Unit of Measure with id "1"
whose displayed_name is "unit(s)", the server receives a long list of ids with
simply the value "1". Also, the server responds with a list of displayed_name,
in this case a list of 40 strings "unit(s)".
With this commit, we always pass unique ids to the server on rpc `name_get`.
jem-odoo