When sending a message through the chatter, the user context (including
the language) is not sent to the server. This causes issues to render
the mail templates in the appropriate language.
closesodoo/odoo#29422
Some product template with attributes never have variants because
the attributes have the field 'create_variant' set to 'no_variant'
So "Tuple index out of range" was raised due to these kind of products.
opw:1911962
closesodoo/odoo#29428
Commit 5804246e0f introduced some improvements to speed up performances.
One of them was to check if a customize_show view was active or not but the
condition was on view.customize_show instead of view.active.
Thus, as that view is always a customize_show, the condition would always be
met.
closesodoo/odoo#29414
Usecase to reproduce:
- Set manufacture step to 2 or 3 steps
- Create a MO
- Go on the PC picking and validate some quantities w/h BO
Traceback because there is no documents to log the activity.
It happens because the function used in groupby and sorted
(in the method _log_less_quantities_than_expected) expect a picking.
The purpose of _log_less_quantities_than_expected is to generate
an activity on the next picking in order to notify that some quantities
will be missing due to the cancelation of the back order. In order
to find the following picking it uses the destination moves from the
current's picking moves.
Picking w/h BO Next Picking (activity to post)
| |
moves -----------> destination moves
However in the case of 'pick components' picking type(PC) the destination
moves are linked to a manufacturing order and not a picking. So it
_log_activity_get_documents return an empty parent since picking_id is
False.
In order to fix it, _log_activity_get_documents only add the tuple
(object where the activity should be log, responsible for the activity)
if the object is not False. It also add a hook in order to add
(mo_id, repsonsible) during _log_less_quantities_than_expected on top
of (picking_id, repsonsible) in order to log activity on MO directly
linked to PC.
This commit also add a missing precision_rounding in backorder
confirmation
opw-1908753
closesodoo/odoo#29385
Since multi-website 4f6ec1cd2a, `website_published` became a computed field
and `is_published` was introduced for storing the old `website_published` value
Still, old SQL select was trying to read `website_published` instead of
`is_published`.
Step to reproduce:
- Create a Membership Product
- Create a Membership Customer
- Add the Membership to the Customer (Buy Membership)
- Publish the Customer
- Go to /members, it will error 500
closesodoo/odoo#29412
Steps to reproduce the bug:
- Create a payment acquier PA with no journal
- Click on "Set payments" on your website dashboard
- On the wizard, choose "Custom payment instructions"
and select PA as Method
- Set a new bank name and a new account number
- Click on "Apply"
Bug:
A traceback was raised because no journal was set on PA.
opw:1916418
closesodoo/odoo#29378
- Create a RFQ
- Send it to the customer
The email sent contains a 'View Purchase Order' button instead of 'View
Request for Quotation'.
We make use of the previous commit to correct the issue.
opw-1915230
Allow to specify the `model_description` when sending an email to take
into account for cases where the same model is used for different
business concepts.
opw-1915230
- Create a PO for a French customer
- Send by email
The body of the email is in French, but some parts (such as the View
button or the footer) are not translated.
The body is translated following the field `lang` of the email template,
in this case `${object.partner_id.lang}`. This is done when opening the
mail composer (so the message appears in French). However, other parts
are rendered only when sending: at this point, the language to be used
in the template is lost forever in the darkness.
To avoid this, we keep a specific context key `custom_layout_lang` that
we retrieve when rendering the custom layout.
opw-1908420
Do not use the model `_description` field which cannot be translated. Use
the `display_name` of the corresponding model instead.
Moreover, `<t t-esc="'%s' % model_description or 'document'"/>` gives
`'None'`, while `'document'` is expected.
This adds a query to some tests, which is expected since `display_name`
requires information stored in the DB, while `_description` is defined
at the Python level.
opw-1908420
This is basically a backport of revision
47479401cb
to gain the performance on the project
percentage satisaction computation
but without introducing the new parent mixin,
which would not be a stable change.
closesodoo/odoo#29354
The correct way to trigger a recomputation of a field is not
to call directly the compute method. The ORM offers mecanism
to do it: we have to flag the field as "recompute to do" and
then call `recompute` method (availble on every models). This
one will call the recompute method of all fields marked as
"to recompute".
This will optimize the performance by doing recomputation in
batch.
Task-1903565
- The `_write` override on `sale.order` create a Next Activity for the
SO's salesperson when changing the SO `invoice_status` to upselling.
If the SO doesn't have a salesperson this code crashes since `user_id`
is required on Next Activities.
To avoid this crash we create the Next Activity only if a salesperson
is set on the SO.
OPW-1914087
The definition of `attachment_ids` on model `email_template.preview` is wrong,
because its table/columns refer to the model `mail.template`. As the field is
only used to preview a result in a wizard form, it does not need to be stored.
closesodoo/odoo#29349
used to fetch debit & credit recorded in Tax Cash Basis Journal Entries
Main
-
By allowing to change the `amount_mnt` var we will be able to change the
values recorded in Tax Cash Basis Journal Entries, i.e, debit & credit
values.
Explanation
-
We want to keep the `amount` just the way it has been computed because
that is right. We don't want to change that.
Our issue is the`rounded_amt` which is the value that is passed to the
debit and credit downwards.
We have only hooked a new method to allow us later inherit that method
and make our own computations regarding the `rounded_amt` which is the
main subject of this PR and later pass it down to the debit & credit
fields as need for localizations that could be facing the problem of
having the computation of taxes at date of invoicing instead of date of
payment.
`amount` var is used here:
`
'amount_currency': self.amount_currency and
line.currency_id.round(-line.amount_currency * amount / line.balance) or
0.0,`
and we are not intending to change that because the value written to the
`amount_currency` field is right.
What we intend is to compute the values for debit and credit fields
which were computed in this method at invoice date, some l18n need them
at payment date, e.g, l18n_mx.
Be aware
-
Do not be mislead by the fact that `rounded_amt` var is the one taken to
do those computations. It is just a mean to the final goal. Rounding is
not an issue and has never been.
Background
-
By allowing this merge to flow we will be able to address the following issues:
https://github.com/odoo/odoo/issues/25057https://github.com/odoo/odoo/pull/17196https://github.com/odoo/odoo/issues/9972
Final Goal
-
Being able to perform the computation of the debits and credits
according to l10n_mx in odoo/enterprise#3137closesodoo/odoo#28991
When activating a filter on a list view,
the environment of the action contained a context with an orderedBy key
which was then used by every controller and model in the various
parallel flows, i.e. changing actions
After this commit, we prevent it by excluding the key when executing an action
OPW 1913190, 1914019
closes#29190
required: [('chart_template_id','!=',False)] doesn't work because you need to fill the chart_template_id
to install a chart of accounts for your company. Then, the transfer_account becomes required before its installation
and then, you are not able to install a chart of accounts for your company.
If installed along with `auth_signup`, it sends an email when creating a missing user authenticated through LDAP.
It is a confusing message that makes no sense, because the user is, from his POV, not actually creating a new user, but just authenticating with a new app with his known company-wide credentials.
Besides, that invitation leads the user to change his password in Odoo, although he probably doesn't want to do that and have a password for Odoo and another in the LDAP server.
The best option is to disable that email completely, which is what this commit does.
closesodoo/odoo#29243
The module `vatnumber` (which is not maintained anymore) uses an
incorrect validation method for Albanian VAT numbers. Therefore, we use
the library `stdnum`, on which `vatnumber` relies for most cases.
opw-1912680
closesodoo/odoo#29280
When analysing the code thanks to Pyflame it cames that the 'prefetch_fields()'
function was runing most of the time. In order to improve the global performance,
I change the context of the move_lines : 'prefetch_fields = False'. It permit to reduce the
time of computation of the prefetch_fields and to avoid the MemoryError.
N.B.: The database of the customer (on saas) contains 1.3 millions of entry and to reproduce the issue
I have to set the HardMemlimit to 0.9 Go and the SoftMemLimit to 0.5Go.
OPW-1910422
closesodoo/odoo#29231
Following BS4 migration and adding sections and notes.
=====
Document templates:
- Remove margin from <p> in "informations" to allow them to be
correctly centered vertically on their container.
- Also add a mt- and mb- on their <div> to better handle them going to a new
line when there are too many of them.
- Add class for section and note to be able to customize them in layouts.
- Add class for price_total to be able to customize it in layouts instead
of relying on :last-child.
- Add "page-break-inside: avoid;" on the "total" table to not split it
between pages when it can be avoided.
- Fix sale report template "Informations" to use col-auto just like invoice
See 6b8d7bb6d6
=====
Boxed layout:
- fix section & note style
- fix borders in general
- fix the total table
Background layout:
- fix section style
- fix the total table
Clean layout:
- fix page number vertical align
task-1889346
closesodoo/odoo#27782
The reference is not copied to the invoice move because the invoice needs the move to get the
right number and then, we need the invoice number to compute the reference.
So, this commit is required to copy the reference to the move after the invoice validation.
/!\ DO NOT FORWARD-PORT!
This behavior has been already fixed in 12.1 but with too much refactoring for a stable branch.
closesodoo/odoo#29391
After 11.0, in a code editor (ace editor) on the frontend we could not
resize the editor or see line numbers.
This happen since:
- in 64d47c0bc5 ace editor (used when editing code) was updated.
- in ajaxorg/ace@5bf78e09 the line number bar was set aria-hidden
- in 9de1bc0ee aria-hidden element were forcibly hidden
Thus the column of line number (and used for resizeing) in the code
editor was unwillingly hidden.
Since we don't want to make change in library, we fix this in our
custom CSS for the code editor.
opw-1912824
closes#29399
Support for string attribute on fields in pivot view was added in 24f7c7ce7f
In some cases, the field is not stored and read_group method is
overridden to allow its use in a pivot view. Such a field does not
appear in the measures dict trying to set the string attribute, leading
to a client crash.
With this commit, the string attribute is set after the non stored
fields were added to the dict.
closesodoo/odoo#29393
Before this commit, we are getting error that product_uom must be
matched because when we're adding line to inventory after updating the
quantity, product_uom changes to Units.
After this commit, error will not be generated as the default value of
product_uom_id is removed.
Fixes#29305closesodoo/odoo#29371
When all days in a calendar don't have the same schedule, it's wrong
to compute the leave duration with the average working time hour per day.
opw:1909145
closesodoo/odoo#29313
Before the fix we were requiring for product.supplierinfo.requisition_id
which is a non existing field of the model 'product.supplierinfo'. I
just change it then to purchase_requisition_id which is the required
field.
This triggered an error when you add a product selled by the defined
vendor for an aggreement type defined as 'Blanket order'.
opw-1914712
closesodoo/odoo#29342
Install stock_barcode.
It adds a barcode to the product quantity of the inventory adjustment view.
On firefox special characters are ignored (CTRL, BACKSPACE, Fn...)
closesodoo/odoo#29245
1. Create odoo instance with "--without-demo=ALL" option.
2. Install Accounting module.
3. Add Chart of Accounts manually (e.g. code 111111 Bank and Cash and 222222 Other Income)
4. Create Journal.
5. Create Journal Entries.
6. Activate multi-company.
7. Set new company to current user and set the new company as current company.
8. Install accounting localization: Accounting >> Configuration >> Settings >> Install More Packages >> (install any localization module)
Before this commit, there was an error because when installing any module,
the environment in which it happens is in uid = 1 and doesn't have a context anymore
Thus, when arriving in the charts of accounts code, the env's user is still 1
Which doesn't mean anything in V12, since it is the system user
After this commit, the user is retrieved from the request
OPW 1911677
closesodoo/odoo#29310
Recent works in the search view (in 12.0) on dynamic filters had an
unfortunate effect: when the user tries to input escaped strings (for
example "test" in custom filters, there was a crash.
The reason is that the JS python parser (or more specifically, the
tokenizer) was unable to parse that as a string. It worked before
because the web client sent the raw string to the server. However, with
dynamic filters, this is no longer the case, and we need to parse
domains to be able to combine them.
In this commit, we modify the tokenizer to be able to work with escaped
strings.
closesodoo/odoo#29324