mail.thread mixin will (re)provide the field 'website_message_ids'.
Models can redifined its domain, since it can differ a bit (blog, forum,
... are not the same).
Even if the domain can differ, we still keep it on the mixin since
it will be required for the new chatter frontend (see following
commits).
When a model contains a field translatable which has a unique
constrain, it is impossible to copy a record. Indeed, the unicity
constrain is always triggered, even if the model takes in charge the
overriding of the copy method to avoid duplication.
Introduced with commit ce7f31b0b0, with the goal to target only
XML/HTML translations. We apply this behavior in case of a callable
translate property, to target only the desired problematic use case.
opw-749481
- Use the form builder to send an email
- Customize the snippet to include the subject and the body
- Send a mail
=> The subject is not included in the email
This is because the subject is filtered out and considered as a
blacklisted field.
It happens because `mail.mail` inherits from `mail.message`. The field
property `website_form_blacklisted` is set to:
- `True` for `mail.mail`
- `False` for `mail.message`
Since we go through all inherited models, the property on `mail.mail` is
overriden by the property on `mail.message`.
It is actually not necessary to go through all inherited models, since
in the case of `inherits`, we copy the fields of the inherited model to
the target model. The check is simplified by only checking the fields of
the current model.
Based on work of @nla-odoo
opw-748926
In an invoice, the modification of an invoice line triggers the complete
recomputation of the tax lines. However, it also deletes any manual
taxes that could have been set (e.g. on vendor bills).
Courtesy of @jjscarafia
Closes#17885
opw-749323
Really apply commit a9ce4ffb22 to POS orders.
Since the creation of a POS order in the backend is a feature which
nearly not used, we rewrite everything related to onchanges. To avoid
breaking the compatibility, the old onchange code is kept. As long as
the user doesn't upgrade the module it will be used instead of the new
onchange.
opw-746827
In field_utils, the parse monetary method was remapped to parsefloat. In this commit, we add a specific parseMonetary method to handle currency specific formatting.
Onchange RPCs return an object that may contain a 'domain' key.
When it does, its value is an object whose keys are field names and
values are the new domain for the corresponding field.
Before this rev., the 'domain' key was totally ignored by the
BasicModel. This feature is used for example in the account.payment
form view (go to an open invoice, click on 'Register payment'): the
domain of field payment_method_id is updated by the onchanges (e.g.
when changing the journal_id). As the domain was ignored, it always
displayed all possible payment methods.
... when reading and writing on a record (especially inside lists).
Before this rev., the context sent when reading a record, and when
writing records inside lists (editable list views) wasn't correct.
This caused an issue in Sales > Products (variant activated) >
open a product with variants > click on variant prices > edit the
prices of a variant: the value wasn't saved correctly (because the
inverse function requires 'active_id' to be in the context and it
wasn't the case).
Fixes two issues in the test environment:
- for unset fields, the mockRead is supposed to return 0 (numerical
fields), empty array (x2many fields) or false (otherwise). Except
for the first case, it was returning undefined, and this might
cause crashes when evaluating contexts or domains.
- the mock environment allows overriding some global properties
like the session, for the test case only. Once the widget is
destroyed, those global properties are reset to their original
value. This wasn't working for models tests, because the destroy
function of the parent widget was never called. This could make
tests fail as they could have been impacted by other tests.
The test changed in this commit had a big issue: it did not properly
destroy the second form view that it created. Because of that, it was
still alive and could interact with other tests, such as the barcode
tests.
This is what happened:
1. var form was assigned to a form view
2. form was destroyed
3. in a try catch, form was reassigned to the result of createView, but
the evaluation of createView crashed (after creating a form view), so the
assignation was not done, and the var form was still pointing to the first
form view
4. form.destroy is called, which did nothing for the second form view.
There is no easy way to get the reference to the form view created by
createView without changing some other code, so we simply remove the
second part of the test, which was not particularly important.
The 'category' key is already present in the manifest.
This duplicated key makes odoo create a new module
category, with a bad xml id
(module_category_accounting_andamp;_finance), since
the ampersand was escaped.
Steps to reproduce the bug:
-create a child contact of a company C
-invite the child contact as a portal user
-sign into the website and place an order w/ wire transfer as payment acquirer
Bug:
The payment term set on the quotation was not taken from the company C and
the default sales person was not taken from company C too.
opw:745091
The reference fields haven't been correctly implemented with the new views.
This commit restores their behaviour.
Note that an small improvement has been introduced in this commit.
Before saas-16, a `name_get` was done for each record (so 80 if the field
was displayed in a full list view), which is not optimal. The calls are now
batched by model (so one `name_get` by model appearing in the field values).
In the editable list, when pressing enter, the cursor goes to the next line and
the current row is saved.
This should not be the case for a textarea (i.e. in the FieldText widget). In
this particular case, we just want to continue editing the textarea.
Some module, such as `l10n_be_invoice_bba`, use the field to provide
information to customers. Basically, if this field is filled in, we
should print it.
This reverts commit 59efea7e31.
opw-748930
- Labels are now left-aligned in xs
- col-md-* sizes of newly added field were not the same
Note: forms should be reviewed to have a proper bootstrap structure and
website_form_editor should be smarter (see task-34451)
task-31510
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
Jérome Maes