Resizing a workcenter line is confusing to the user since a resize
only changes the `date_planned_end` and recalculates the `date_planned`.
However, a user would expect that a resize changes the duration, which is
not the case.
To avoid the confusion, it is not allowed to resize the tasks anymore.
opw-676762
It makes no sense to recompute delivery costs at each update of the cart;
furthermore, it prevents users that already selected a carrier to remove
the last products of their carts
This fix is additional to e4e1e571c2
Used case:
-Configure company in EUR, and user in multi-currency
-Create a purchase order in USD and confirm it
-Click on the smart button "0 invoices" then click on "create"
Result before the fix:
The system created an invoice in EUR, currency of the company,
instead of in USD, currency of the purchase order.
Result after the fix:
The system created an invoice in USD, the currency of the related purchase order.
opw:677568
Form views with a FieldBinaryImage produced a traceback (only visible in the
server-side logs) when creating a new record from an existing one, because the
fields were re-rendered before being updated (in this case reset to their
defaults). In the case of the FieldBinaryImage, as the field wasn't reset yet,
we tried to load the image of a null id, which produced the traceback.
This rev. ensures that the fields are updated before being re-rendered when
switching to another (possibly new) record.
Note: this is spaghetti code, several re-rendering are triggered when switching
between records (e.g., when updating the fields value, when actualizing form
view mode). This should definitely be refactored/simplified.
Before this rev., if an error occured during an RPC handled by the
data_manager, the RPC result was stored in cache anyway, and there was thus no
other way than refreshing the page to get correct result for that RPC.
`debit_move_id` and `credit_move_id` of
`account.partial.reconcile` must be required.
Not having one of them set on this model
does not make sense, you cannot have a reconciliation
with a debit move but without a credit move, for instance.
Databases already having the trouble,
having partial reconciliations without
either a debit or a credit move,
had issues for the computation of the
`payment_move_line_ids` compute field,
which relied on the fact these fields
were supposed to be required. This revision
makes a retro-compatibility patch for these
databases already having the issue.
opw-677709
The left margin of the graph doesn't take into account the width of the
maximum Y-axis value. In case the values are high (> 10^7), they are
cropped.
The fix is to adapt the left margin as a function of the size of the
maximum value.
opw-676538
Add inputs e-mail address and country
when creating a newdatabase
This will provide the installation of the correct
chart of accounts at the installation of Accounting
Use the provided login as the admin login,
and set the email on the partner
if the login set is an email
Set the country on the company (and its partner)
The countries are parsed from XML country list
We take the opportunity to repair the `label for`
which bind the label with the input only if
the `id` attribute of the input is set with
what is set in the `for` attribute of the label
An issue occurs in the following situation. Several cash journal are
configured for a given PoS, and a user performs a refund (the
transaction contains only a refund). In this case, the wrong journal
might be selected. This is because a payment line of zero is not sent to
the backend, and therefore an arbitrary journal is selected.
opw-676229
The _auto_init method was overriden without keeping the return value of
the super on some models.
This break the new stored computed fields computation at field creation.
Closes#11985
opw-677232
Before this commit, in some cases, clicking on 'save' button, then on
other buttons (like 'validate' in invoices) had the unfortunate effect
of applying twice the changes in some cases.
More specifically the problem appears when:
1. an onchange is triggered (for example, taxes in invoices)
2. the user clicks on 'save', buttons are disabled
3. the 'save' actions is completed, the buttons are enabled, but
the on_button_save still does some work: triggering event, and
reloading the view
4. the user clicks on 'validate'
5. the onchange completes, this triggers some more work
Our only protection against such interactions is right now the fact that
buttons are disabled/enabled. In my opinion, there should be a way
to guarantee that actions are properly serialized (that is actually what
a mutex is for... just saying). But the code of the form view/list view is
too coupled, and such changes are quite dangerous. A real refactoring
of those is needed at some point in the future.
Before this revision, the installation instructions where
Community-centric, which led some customers to believe
that they had to install first Community then Enterprise.
This commit makes the instruction compatible for both editions.
purchase.order have been rewritten with cb01be2
It was not taken into account for intrastat who still used the now not
existing "location_id" on purchase order.
This commit use instead the method _get_destination_location which
should be equivalent.
opw-677497
If a custom report's render_html raises a KeyError for some
reason, Report.get_html would swallow the exception and fallback
on generic HTML rendering, usually blowing up with unfathomable
errors of missing rendering context data.
Check if a custom report object exists instead of waiting for a
KeyError.
Nicolas Martinelli