The "Uninstall" button on the module form no longer changes the state of
modules, so that cancelling the wizard will not unexpectedly perform the
uninstallation. The uninstallation is performed only by clicking on the
"Confirm" button on the wizard.
Moreover, the wizard provides clearer information about the impact of the
uninstallation: what apps/modules will be uninstalled and what documents
(models) will be lost.
Within the scope of P3 compatibility, a StringIO was replaced by
BytesIO in b4429c2a91, however I missed
that BytesIO is much stricter about types than StringIO *even in
Python 2*. Some bits of text would sneak up in PoFile.write or
PoFile.write_info and blow up the export.
The BytesIO makes sense for output (tgz is definitely not a text
format and base64 is a bytes -> bytes encoding), but ensuring the
entirety of PoFile worked on bytes seemed distasteful (and lots of
changes), it seemed more sensible at all levels that PoFile would make
sure to properly work on *text*, and to add a text adapter wrapper
around the BytesIO buffer.
io.TextIOWrapper was almost perfect (it closes the underlying stream
on close but that can be worked around) *however* it turns out
TextIOWrapper does not work on Python 2's `file` objects... so use the
older codecs.StreamReaderWriter which should be able to do the job
properly.
fixes#17834
As of June 15th 2017, according to
http://proxy-pubminefi.diffusion.finances.gouv.fr/pub/document/18/22503.pdf
Will not be required for all FR companies.
The certification will only be required for POS software, not for accounting
softwares.
Disable autoinstall, waiting to have more information on the changes to be voted.
Closes#17771
Steps to reproduce:
Let's consider product P tracked by serial number
P has a manufacture BOM B with Q as componenent
- Produce P with serial number SN(with MO)
- Send P with SN to a customer A(with SO and DO)
- Force availability on P to a customer B(with SO and DO)
- Return P to stock for customer A.
Bug:
The tracability for P removed the component Q(consumed_quant_ids)
when reconciling the negative quant(generated for B) with the returned
quant from A.
opw:744424
With the new client web from v9, we start the new action before to destroy the old one.
When we switch from Apps (store) to Update and vice-versa, iframe was not loaded correctly.
In case of the Apps widget, we are binding event of the new iframe during the start,
and when it is ready, we destroy the old ifram and so unbind the listener of 'message.apps'.
Using a uniq id, we ensure to bind new event, and only unbind old event during the destroy.
The translate feature of widgets html and html_frame had been
broken by the new views refactoring. This commit restores it for
the html widget, and removes it completely for html_frame as it
wasn't working correctly before the new views anyway (moreover,
it had already been disabled for mass_mailing: de403dc1ab).
This commit also ensures that the changes are correctly saved for
the html_frame widget. Note that this widget still needs to be
converted to our new coding guidelines.
Each time the invoice is printed, it shows an updated remaining amount on the invoice. The first print, though, is kept as canonical reference as attachment.
Was PR#16343
Before this commit, the discard confirm dialog was directly shown
without waiting for the write RPC. For instance, it the user clicked on 'Save'
after editing a record, and then directly clicked on another menu or on the
breadcrumb before the write RPC returned, the record was still considered
as dirty and thus the confirm dialog was displayed. We now wait for the RPC
to return before checking if the record is dirty, so that the confirm dialog
is only displayed when the record is actually dirty.
In the website portal,the Sales Orders are always rendered as superuser
after access rights check. This is not the case for invoices, which can
lead to access errors when the user tries to download the invoice PDF.
To solve the issue a new route is created. It handles the access rights
checks, then access the invoice document as a superuser.
opw-747854
For example the portal user has restricted access to product template,
this can lead to an issue that should not be in this instance that is
checking if the product template correspond to a product sold.
opw-748480
closes#17871
When importing translations with a csv, the state of the translations was
always set to "To translate" even if the state was "Translated"
due to function _inverse_source.
PS: Making self.source when self is considered as record set could lead to an error.
The return in this function was not needed.
In old API this function was called just for one record.
So this function expect only one record at each call.
opw:747877
- Set a user with 'User' access rights in Manufacturing and Inventory
- Create 2 products tracked by lot (A and B)
- Receive some quantity of B, define the lots.
- Create a BOM for A, depending on B. The BOM must use routing with at
least one workorder
With the unprivileged user:
- Create a MO for 1 unit of A
- Update quantity to 3
- Plan the MO
- Go in workorders, start working and set the lot numbers for A and B.
- Finish the WO => Access Error
opw-748825
The ETA displayed on a mailing should only switch from the scheduled
date to the next cron run when the cron run is after the scheduled date.
Previously it could jump in the past on the scheduled date, if the next
cron run was in the past (delayed or in progress).
Purpose
=======
If you create an opp from the kanban you can select any contact (even if not marked "customer")
If you try to add a "non-customer" for the same field from the form view you cannot.
Specification
=============
Apply the same behavior than on the form view.
session.rpc should not be used anymore. The function '_rpc'
available on widgets should be used instead (with the correct
params).
Also, 'session' is no longer a widget attribute.
When the value of a many2one field with widget selection was unset,
it's value wasn't actually set to false in the BasicModel. It was
set to a virtual id like 'virtual_294' instead. This caused a
traceback when this value was sent to the server, obviously.
This was for example the case of the Register Payment form view
(accessible from a customer invoice), when the user selected a
payment journal, and then unselected it (the virtual id was then
sent to the onchange RPC).
The MonetaryField can be rendered with or without a currency. The
currency can change during the lifecyle of the widget (e.g.
currency field in the view, whose value is set by an onchange).
More precisely, the widget can be instantiated without currency,
then a change on another field can trigger an onchange which sets
the currency, and our monetary widget is re-rendered with a
currency.
Before this rev., this wasn't supported in edit mode because the
$el's root node was different if there were a currency or not
(it was an input if there were no currency, and a div containing
an input and a span otherwise). This root node being rendered only
once (at the creation of the widget), the widget wasn't re-rendered
correctly if the currency was suddenly set or unset.
This fix makes the widget behave uniformly whether or not there is
a currency, so now it is always a div containing an input (and
optionally a span if there is a currency).
A traceback occured when trying to create a BOM by going to
Inventory > Master Data > Products, on a product form view clicking
on the BOM stat button, and then on 'Create'.
This was a context problem: the context of the 'Products' action
was passed to the 'BOM' action without removing action specific
keys like 'default_*' or 'search_default_*'. For instance, it
contained a 'default_type' key, and as type is also a field of the
mrp.bom model, the python tried to interpret it, except that the
given value wasn't a correct value for mrp.bom.
When a button is clicked, we mix contexts coming from different
places to execute the new action. For some of them, we already
filtered out those action specific keys. This fix is simply to
make the piece of context adding the problematic keys pass though
the filter as well.
When x2many fields have to be evaluated in domains (e.g. ['id',
'in', some_x2many_field]), they must be evaluated as the list of
ids in the relation (whereas in contexts, they are evaluated as a
list of commands). Before this rev., they were always evaluated as
a list of commands.
Note that this didn't work neither before the new views.
Datapoints of the BasicModel store the data fetched from the
server and changes done (not saved yet) by the user. For x2many
fields, datapoints are of type 'list' and have a 'res_ids' key
containing the ids of all records in the relation. They also have a
'data' key containing datapoints of type 'record', representing the
records in the relation that have been fetched (with a limit set to
40 or 80 depending on the subview used). So basically, the length
of res_ids may be different than the length of data.
Before this rev., the changes in x2manys were saved under the key
'_changes' as a duplication of the content of 'data', i.e. same
list of datapoints of type 'record', modulo the changes done (it
contained the new records added and didn't contained the removed
records, whereas the 'data' remained unchanged). This didn't worked
at all when there were more records than the limit in the relation.
Indeed, when this happened, the commands to send to the server
couldn't be generated correctly.
This rev. modifies the way changes are stored in those datapoints.
Now, each change is stored as an operation. An operation could be
of type 'ADD', 'REMOVE', 'REMOVE_ALL' or 'UPDATE'. As before,
'data' remains unchanged and always keeps the datapoints of records
that have been fetched (the ones that are currently displayed in
the list or kanban subview). This way, commands can now be properly
computed.
This had a nice side-effect of fixing two other bugs linked to
x2manys.
First, when used in a context (e.g. {some_key: some_x2many_field}),
the value of some_x2many_field (i.e. a list of commands) was always
[] if the field was invisible="1" in the view, because it's
subrecords weren't fetched, and the generated commands were based
on them. Now, they are generated from the list of res_ids in the
relation, so it works fine.
Second, the x2many records are supposed to be sorted client-side,
after being read, and after each edition. This was working in the
first case, but not in the second. Now it's working even after
a record edition.
This rev. also correctly sets the 'parentID' and 'static' keys in
datapoints.
Finally, we also fixed the pager in x2manys as it was badly
displayed (small less tweaks).
Uninstalling Sales with CRM still installed lead to an error
when clicking on CRM app because the dashboard_graph_model was not
updated for each crm.team record.
opw:748099
Some reports require additional information to render. When
accessed in Odoo, the user has to fill a wizard to provide those
information. However, when these reports were opened in Studio,
it crashed as those information were missing (we don't pass
through the configuration wizard in this case).
This fix checks if all the required information are given before
trying to render those reports, and it displays a warning in
the logs in they are missing, which is better than a traceback.
Naglis Jonaitis