- Create a product A with a barcode, UOM as 'Unit(s)' with a BOM
- Create a MO for A with more than one unit, validate
- Print the 'Finished Product Label (PDF)'
A single label is printed for all units, although it is not logical: a
label should be printed for each unit, as already done for the Zebra
labels.
In case the product UOM is 'Unit(s)', we print a label per unit. To do
so, we use a template similar to `label_transfer_template_view_pdf`.
opw-2091663
closesodoo/odoo#39311
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a customer invoice or a vendor bill
- Add a product with any pre-defined tax
The tax line is not added.
This is because the account 2221 is set as 'Payable' instead of 'Current
Liabilities', as it is the case in other localizations.
For reference, the tax line is created then removed because:
https://github.com/odoo/odoo/blob/db2e6bc600364c00e8a1d528d4b17ae052ecd41e/addons/account/models/account_move.py#L816
The line is part of `existing_terms_lines` instead of `others_lines`.
opw-2089955
closesodoo/odoo#39309
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do not use `tickets` which is a recordset with more than one record.
opw-2092231
closesodoo/odoo#39312
X-original-commit: 3e2d968c55542426746b287c556b5fb05d59fdcb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit c95acd624e added support of sending tickets to client directly
by email. However parameters management in the business method allows to send
void emails or to spam people quite easily. Moreover missing translations
marks prevent from translating mail content.
This commit fixes that by ensuring current user is member of pos user group.
Code is also a bit cleaned to ensure mail values are correct. Finally
translations marks are added to allow content translation.
closesodoo/odoo#39275
X-original-commit: 884c98984d45d0875fe5b0d230a70408d8f75f6d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before update
When we creating opportunity from lead and select option 'linked with existing
customer', partner information is not filled up in followup section.
After commit
When we creating opportunity from lead and select option 'linked with existing
customer', partner information is correctly filled up in followup section.
This commits fixes that behavior by calling onchange_partner_id when converting
a lead to an opportunity.
Task ID 1974504
closesodoo/odoo#33073
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before commit
When we create an opportunity manually from the Kanban view and associate
a customer to the opportunity, the "Initial Contact Information" doesn't
appear in the "Followup" tab on the lead so we have to reassign a partner
second time on the opportunity.
After commit
When we create an opportunity manually from the Kanban view and associate
a customer to the opportunity, the "Initial Contact Information" will appear
in the "Followup" tab on lead.
This commit adds missing fields as invisible in the quick create view so
that the onchange updates them. As original author say, "to make onchange
works fabulously".
Task ID 1974504
- Teacher can now see the progress of his students on the attendees' list.
- The completion of a course was recomputed even if the course is completed
now it's fixed to 100 when completed.
- Added a progressbar in course page in front-end to allow the user to see
it's progression. When completed, the tag completed is displayed instead of
the progressbar.
- On slide page in front-end(normal view or fullscreen) when a course is
completed, display the tag completed instead of the progressbar.
- Removed completed state on course "Taking care of Trees" for portal user
because it was not the case.
task-2049689
closesodoo/odoo#36608
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a new field "completed_slides_count" in slide.channel.partner
completed_slides_count has the same role as field completion before this commit
Now the field completion is a % of the completed slides
task-2049689
Before this commit, lists having a section or a note would have a horizontal
scrollbar in readonly mode.
Now it has been removed and the list stretches properly according to its parent
size.
Task 2086594
closesodoo/odoo#39301
X-original-commit: cbe26b3a3ac5ef3d79695cf44874e01087a35ef9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, all the computation of the default widths for column
headers was done before the list was attached to the DOM, meaning that no
column was actually visible. This was a problem since columns that are
meant to stay unseen were taken into account in the calculation of relative
column widths.
Now, the same algorithm runs once the columns are visible so that invisible
columns can be properly excluded.
fixes#38744
Task 2076721
X-original-commit: 4bf98b47898b075049975dfe597f0fb92c7c14d1
Before this commit, the `width` attribute was interpreted by a jQuery node generator
function as a `style="width"` property and gave an incorrect width value to the affected node.
Now, the `width` attribute is automatically plucked in the list renderer in the
specific function used to render buttons.
Task 2076721
X-original-commit: c67b36c00ca263f51e0dd49d6e38702c4d614289
Some external ids of account.fiscal.position.tax.template were
duplicated
closesodoo/odoo#39287
X-original-commit: 707084af713d90ab71f7eab389bed493ae86c68a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The queries made by the method `_is_an_ordinary_table` represent about
8% of the time to do a full Odoo installation. Use a cached query for
all tables on the registry to reduce that time to some negligible
amount.
closesodoo/odoo#39262
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
`_` is not available when loading this part of the template, leading to
an error on `_.str.trim()`.
We can simply use `trim()` to do so. By the way, `google_analytics_key`
is now trimmed automatically when adding it in the settings, so this is
only useful for migrated databases.
Fixes#38891
opw-2089296
closesodoo/odoo#39269
X-original-commit: a492047e9a064beecbe0611c3f7aef5172406eb1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of this commit is to remove code coming from old features,
implementations and that was not completely cleaned.
Including
* remove support of old "reply" composition mode which is simply a comment
with a parent message, and is deprecated;
* remove support of old "mail.compose.message.mode" context key that was
used in Odoo 6.1;
* remove support of message_id default value in context instead of
default_parent_id;
* remove old redirection of user / partner post. This code come from
old age when people were able to post on their "profile" by posting
on their user;
* remove unnecessary method for selection field;
* remove unused imports to clean a bit code;
We also make some optional parameters in rendering methods mandatory to
ease code understanding and future modifications.
Task ID 1853147
PR #39272
Purpose is to prepare future cleanups and speed improvements. In this commit
we use create multi on mail.mail, allowing to batch their creation when
necessary.
Task ID 1853147
PR #39272
When a BoM is using a component with a quantity required set to 0,
tracebacks were occuring when computing the available quantities
for the kit.
Fixes#38807closesodoo/odoo#39267
X-original-commit: 7676269ba56c8e293ef4cd3dffbe7eccbad4a9d0
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, when clicking inside a snippet which is already
enabled, it was disabled then re-enabled... which had the side effect
of calling onBlur/onFocus methods. This can be a problem with some
onFocus/onBlur implementation relying on the old behavior.
Note: this commit restores the exact same behavior as before. If an
internal snippet of the active one is clicked, then we still call the
onBlur then onFocus for the old active one (the parent) as the actual
enabled snippet changed (even if it is simply a child snippet).
closesodoo/odoo#39261
X-original-commit: 076992bdf099f3a645c9a1ef6df2cdcccbf1c2b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
For maintenance reason, keep only one CoA
Update the translation files to reflect the changes
Modify the addons/l10n_cn/data/account_tax_group_data.xml to remove
some tax group
closesodoo/odoo#39226
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Records were filtered so not every record was set in the for loop
Fixesodoo/odoo#38992Closesodoo/odoo#39071closesodoo/odoo#39234
X-original-commit: f7d5ba6f9ffccecffbb5b851bd2770ecef28520c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The nightly clickall runbot fail due to a crash of the underlying chrome
browser used to run the test suite. The problem is related to the
resources the browser is using. We leverage the problem by starting one
dedicated browser per app.
closesodoo/odoo#39190
X-original-commit: 228e57d980839bd2b4e9123bf26f8a64de2ae6ab
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Since saas-12.3, deferred actions use native promises. This has the
annoying side-effect of force-deferring promises even if they are
resolved at once... and we relied on the opposite behavior for some
call made in _setActive or option methods.
In master, we should review the async logic of snippet options. Right
now we will rely on the fact those promises are resolved at once but
that we need to avoid for their "async part" anyway. The _setActive
method and the option methods are thus still working synchronously in
stable, despite the new force-deferring promises.
Also, with old promises, when we waited for the resolution of multiple
deferred, the resolve handler received the multiple results as
individual arguments. Now it receives all the results in an array as
a single argument. The resolution of action demands had to be adapted.
closesodoo/odoo#39171
X-original-commit: 30d15315a73c1fa34ada86371b06c02b6375db89
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The basic ORM methods should not silently discard unknown fields, as
they may be a sign of broken code.
X-original-commit: 9595dd06a1d349b2fb84969374d57c32a5faab74
Before this commit, having a `customize_show` on an ir.ui.view record in a
theme module would be ignored when creating the theme.ir.ui.view as the field
would not exists.
Actually it would log a warning on create (module install) and raise a
traceback on module update (theme update).
closesodoo/odoo#39216
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Was comparing b'0x02' and '0x02'
closesodoo/odoo#39214
X-original-commit: 838cb0e8c10de4229c8b04592aefa1808771bbb3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commits fixes user duplication.
Suppose there is a monetary field, with a currency_field that is a related.
When going through model's _create, we do:
`if field.type in ('one2many', 'many2many'):
self.env.cache.set(record, field, ())`
knowing that thse values are false, with the intent to clean them later:
`for record, field in cachetoclear`
However, when setting the scalar values, we go through:
`accessing cache_value = field.convert_to_cache(value, record)`
In the case of the monetary field, this depends on another field value
(the currency_field). If it is a related, we can access its value.
However, at this point, if we check any access rights, we might use the value
of a relational in cache for which the value is incorrectly set to False.
In the case of the user, this is what happens: it inherits its currency_id
from partner, as well as its debit_limit which depends on it.
When the access if checked, company_ids is set to False in cache.
So when going through the rule 'user rule', which checks that the company_ids
intersects with the env.companies.ids, the result is always False.
In some way this is essentially hiding the problem, but the true fix is
probably not feasible in stable.
opw 2086661closesodoo/odoo#39017
X-original-commit: aa05a9359b42317261c8e7ffcadbeb9fe74dcd58
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When marking as done a MO, we use SUPERUSER to create analytic line
as an MRP user does not always have access to analytic items. There
is however a default value for company analytic line defined to the
user's context company, so we need to use the current company of the
real user instead.
closesodoo/odoo#39209
X-original-commit: 14aade9341bf9d61cd21de948755fc339ae512ea
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
You need to provide a small part of the code, because to avoid fraud, google
make several request to be sure that you don't allow all codes :)
So the 'WPS' solution was dropped, now we take the first request from google
that match the part provided, as the good one, and refuse all others requests.
task-2086915
closesodoo/odoo#39186
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Chart of Accounts (COA) Template for Lithuania's Accounting (VAS-15).
Data is multi language (English and Lithuania).
This module also includes:
* List of available banks in Lithuania.
* Tax groups (to map different tax amounts).
* Most common Lithuanian Taxes.
* Fiscal positions for different countries/groups.
* Account Tags used for reporting purposes.
closesodoo/odoo#39187
X-original-commit: 888245f1a4307bd626cb5f55a3dff09898254790
Signed-off-by: Josse Colpaert <jco@openerp.com>
In deliveries slips, you can directly create a new serial number.
If you have multiples companies, a field "company" appears.
But if you have only one company, it doesn't appears and there is
no default value for it.
As the field is required, it returns an error "Company field required".
Before this commit:
- The company_id field in stock_production_lot model does not
have a default value.
After this commit:
- The company_id field has a default value which is the user
current company id.
OPW-2083099
closesodoo/odoo#39170
X-original-commit: 7b6d87519d3ba50688f9f49442cc3814ee427816
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Start odoo-bin using a tier module (like `python3 -m pdb odoo-bin`), the
odoo/addons __path__ contains the relative link to the modules instead
of the absolute link like when directly started (`python3 odoo-bin`).
This cause trouble importing modules because it reuses the relative path
from within other directories.
closesodoo/odoo#39182
X-original-commit: 941e051fc6b33e7a90400c77d63d589049b027a6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit https://github.com/odoo/odoo/commit/dba478332681dd21a39c4a183c002b1cf6e046d2, a survey can have questions with no section
associated, which means 'page_ids' field will be empty.
This prevents to display some questions of a survey, as we are
still expecting a structure page/questions. To solve it, we first
append questions with no sections, then all other questions.
closesodoo/odoo#39113
X-original-commit: 149657cfd696e5065b55519927973fa785cc0e22
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
This fixes a regression introduced by 291a0e99d137142bd24addd1054c1357ddd7125a.
closesodoo/odoo#39178
X-original-commit: 852ee32e3419c210a3844b0f943af8dd2bbdae88
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With Anglo-Saxon accounting, invoices with stock_moves on a product
having 'real_time' valuation cannot be validated: there is a user error
when the interim account is not reconcilable.
We modify _anglo_saxon_reconcile_valuation so that we do not try to reconcile
when the account is not reconcilable.
OPW-2080180
closesodoo/odoo#39167
X-original-commit: 7174bd2f508f33454b7167de7d01ca8824404bf9
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Nicolas Martinelli