Fixes the issue #1216 (follow the link for more information). The issue
was caused by a hack in list view: the magical suffix __display is used
in render_cell to determine if a many2many field should be updated. This
commit simply makes sure that old many2many fields + __display keys are
cleared.
A better way would be to redesign/refactor the list view to avoid that
hack in the first place. But this would be a much more complex task.
if the bom is phantom and has no line, we attempt to find a new bom with the default product uom
This is possible that we find the same bom that the current one
In such a case, we must not explode, to avoid recursion.
If a company contact (a partner with a company set as parent) had invoices, and the company of this contact was duplicated, all the invoices lines were duplicated, on the original invoice moreover (new lines were added on existing invoices)
When the user was in timezone UTC + 1, and added a project.task.work which created an analytic entry line (timsheet activity), if the datetime was set to 11/25 00:00:00, the date on the analytic line was set to 11/24, because this was the truncated stored value(UTC Time), which was 11/24 23:00:00
Set a default value for factor when creating a new uom.
Could not create a new UoM with type reference (if creates a reference uom, no need to pass a factor).
Change the readonly filter to (type = bigger) to make the field writable for reference uom.
This is needed to force the reset of the factor when switching of type (onchange_type).
As the field was readonly, kept the old value for factor.
This rev. 7307227 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned')
Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining.
Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus.
We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary.
opw-617235
The delivery of a purchase order was not keeping the currency and cost price
from the purchase order for the reception. This was problematic for orders where
the invoice was generated from the picking (Invoicing Control: Based on incoming
shipments). The currency of the purchase order was kept while the cost was the
one in the company's currency.
It's better to keep the currency of the purchase order to make the invoice as
it's usually the one expected (and not convert everything to the currency of the
company). opw 615555
This rev. 06104ba553
Added the dirty flag on the o2m field when the editor of the editable list was enabled (meaning that the editable list has been altered)) because the dirty flag was not set correctly by the one2many during the edition, at the time.
It looks like this is now the case
Besides, as now, we valid all the editable list of the form, wether or not the editable list was altered, we must not set the o2m as dirty anymore.
First, name_search searches on default_code, then, if the limit is not reached, it searches on the product name
The results found from the default code search must be removed from the search domain when doing the search on the product name, to avoid having results already found by the search on the default_code
opw-618015
When a picking is confirmed, the generated account.move(.line) should take the
company, accounts, journals and period with the same company as the picking,
not the one of the current user.
This was problematic if a user in a company confirm a picking linked to
a purchase order done in another company.
For real time valuations, the generated accounting entries were mixing both
companies.
Fixes#3466
search bar does not suggest date field format based on user's locale and always shows based on mmddyy using Date.parse, opw:615276
Note: starting in 9.0, datejs has been replaced by momentjs, so this
problem should be solved in a better way.
date field on a project.task.work is not required while it is on the hr.analytic.timesheet (with default value).
Avoid error if fill a task work without date, fallback on context_today.
The field bom_id is required on a manufacturing order and deleting a mrp.bom would block the current mo.
Restrict the suppression for manufacturing order in progress.
Fixes#3417
Timesheet activities (hr.analytic.timesheet) are generated when a work activity (project.task.work) is logged on a task.
These are updated if the project of the task is modified.
This patch applies the same behaviour for tasks without project, the timesheet activities are generated once a project is set on the task.
To avoid redundency in the code, extract the computation in a distinct method.
Fixes#701, opw 609481
once widget extended with ReinitializeFieldMixin, the event binding with the binary file input and the on_file_change method can be done in initialize_content instead of start
This fix is related to d36c8b5c9b
The add attachment button should be displayed while being in edit mode, but not in view mode
As the widget depends on the form actual mode, the widget should be re-rendered each time the actual mode changes
This is the point of the ReinitializeFieldMixin class
The report includes all due payments, not only the one after the maturity date.
The maturity date is displayed in the report so no confusion is possible for payments below the maturity date.
Fixes#3064
To valid all editable list line, we iterate on the lines and set the editor form with the line value, using set_value.
The _inhibit_on_change_flag should be set to True to avoid triggering on changes events
opw-617395
When validating a SO containing a `make to stock` + `manufacture` product
(with bom + orderpoint), we have the following stock moves:
* Product move
* Manufacturing order
Selling 1 such product would yield 2 as incoming quantity, an
inconsistency that this commit solves by setting the location_id of the
product move to the MO's location_dest_id (in the same fashion that
the create_pickings method does in an mts/buy case)
opw-616229
This is related to rev. a218a9ed3f
The condition is good, but not in the right place: It should be done once all read_slice (all columns records) are fetched, not at each read_slice end
Some prices, as standard_price, being a property, are company dependent. Therefore, when browsing as superuser, force_company is mandatory to get the property of the user company
[FIX] account: Preserve analytic account on tax lines which are on same general account as invoice line
After careful analysis, I'm now convinced it is a good thing to preserve
the analytic account on taxes line which have the same general account
as the invoice line.
This is the best default case and will save time for users,
while leaving the flexibility to adapt the analytic account on
taxes manually.
[FIX] account: Error when manually adding analytic account in the generated tax lines on an invoice
fixes#374
fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822
The fix considers invoice tax lines with different analytic account
are equivalent for the purpose of checking if the list of tax line
is complete.
Caveat, this changes the structure of keys in the dictionary
returned by account.invoice.tax's compute method, I suppose this
is ok for the master branch.
opw-617036:
In my current timesheet, if you add a a required field on the timesheet ids lines, and add data in the summary tab, it was possible to validate the timesheet lines while requried fields were missing.
When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move.
This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed.
This avoids trying to update the stock.move with a uom at False. opw 616844
This is a workaround for an ORM limitation. A stored function field is
not updated when it should if the "source" field is also a stored function
field
Pierre Verkest
Denis Ledoux
Danimar Ribeiro
Martin Trigaux
Frederic van der Essen
Samus CTO
Rifakat Haradwala
Frédéric Van der Essen
Dhs-odoo
Ravi Gohil
Julien Legros
Christophe Simonis
Olivier Dony
Manuel Vázquez Acosta
Stéphane Bidoul
Thibault Delavallée
Paramjit Singh Sahota
Mohammad Alhashash