To reproduce the issue:
- Go to website > Add language > Add blocks to your homepage and
translate it.
- Make translations on the "Contact us" page (or a new custom page).
- Install a new app > The translation of the homepage is lost (only on
homepage).
Explanation:
After [1], The `_load_module_terms()` method was updated on website
module to copy translations from base to specific views when module
translation is loaded. And since [2], the translated field's column is
either NULL or a JSON dict mapping language codes to text (the field's
value in the corresponding language).
To explain what happens exactly when new app is installed, let's suppose
we want to load module translation for the config {'en_US', 'fr_BE'} in
the following situations:
S1 (e.g. "Contact us" page):
-=-=-=-=-=-=--=-=-=-=-=-=-=-
```
generic_arch_db = {
'en_US': '<div>Generic (EN)</div>',
'fr_BE': '<div>Generic (FR)</div>'
}
- specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Specific (FR)</div>'
}
```
`_load_module_terms()` will copy translations for 'fr_BE' from generic
to specific `arch_db` (using generic translation dictionary).
result:
```
new_specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Updated Specific (FR)</div>'
}
```
S2 (new custom page):
-=-=-=-=-=-=--=-=-=-=
```
generic_arch_db = NULL
specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Specific (FR)</div>'
}
```
result:
Nothing to do here (only specific version), the specific translation
will not be updated.
S3 (e.g. website homepage):
-=-=-=-=-=-=--=-=-=-=-=-=-=
The generic view has no translated `arch_db` (only the 'en_US' version):
```
generic_arch_db = {'en_US': '<div>Generic (EN)</div>'}
specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Specific (FR)</div>'
}
```
`_load_module_terms()` will copy generic translations only for languages
available on "generic_arch_db" and the 'fr_BE' version will be lost.
result:
`new_specific_arch_db = {'en_US': '<div>Specific (EN)</div>'}`
The goal of this commit is to prevent this behaviour by keeping the
specific translated `arch_db` even when the generic value has no content
for the translation language.
Remark: This behaviour occurred while loading module translations,
as a consequence, the specific translations are also lost when the
website module is updated.
[1]: https://github.com/odoo/odoo/commit/94db81d8d28c4cbc7b51ae1688c9362042ee3619
[2]: https://github.com/odoo/odoo/commit/ef00294e7189359c47638c4a71626f1937395edb
opw-3083480
closesodoo/odoo#108477
X-original-commit: 91a9c870eede96040ac49d2375fe0e18342342e1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Luxembourg added new fields and modified some rules for VAT reports: monthly, simplified, and annual.
- Add new fields
- Adjust formulas
task-2993792
closesodoo/odoo#108472
X-original-commit: f5101ea5f5da4e27a1e44490231eb8cf28c47e08
Related: odoo/enterprise#35154
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
The delivery slip of a picking with an operation type where 'Move Entire
Packages' is enabled doesn't print the delivery address
Steps to reproduce:
1. Go to Settings > Inventory > Operations and enable 'Packages'
2. Go to Inventory > Configuration > Warehouse Management > Operations
Type
3. Open operation type 'Delivery Orders' and enable 'Move Entire
Packages'
4. Create a new transfer with operation type 'Delivery Orders', add a
delivery address and a move and save
5. Mark as todo, put in pack and validate
Solution:
Always use the partner of the `move_lines` in the delivery address
Apply the same logic to the address used in the picking operations
report
Problem:
The delivery slip always uses the partner of `move_ids_without_package`
but there might not be any if the picking uses packages
opw-3091139
closesodoo/odoo#108465
X-original-commit: d113e0d7a5aa1c1f6bb933771cda4a3365361ba0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Current behavior:
When a global discount is applied, it is considered as a regular
orderline when computing the order discounts. Because of this if you
applied a coupon and a global discount, the pos would add a discount of
infinity value.
Steps to reproduce:
- Create a promotion with a discount of 10%
- Create a product with no taxes
- Enable the global discount feature, and make sure the Discount product
has a tax set on it.
- Create a new order, add the product, apply the promotion, and apply
the global discount.
- The order will have a discount of infinity value.
opw-3094784
closesodoo/odoo#108441
X-original-commit: 1ea082b933a9583a9af1839164e919a0ac7512f9
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When checking if a line in traceability report is unfoldable,
`_get_move_lines` is a costly operation and should be executed last when
all other conditions are satisfied.
closesodoo/odoo#108119
X-original-commit: 36697278b6130e066deb994d879a8567e45d3451
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Description of the features in this PR:
add the date deadline to the order of tasks (sort priority)
add the day of the week (only the first 3 letters) for the recurrence message in recurrent tasks
display the name of the project in the action instead of 'Project Sharing'
By changing the sorting order of the Project.Task model
some indexations in the tests didn't point to the right tasks
Now each task that has a deadline will be placed in front of other tasks (except for the high priority task)
Task-3034635
closesodoo/odoo#105701
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
On changing style of a list item to normal it wrapped the content in a <p> which
results in extra spacing to next list item.
After this commit:
Now the content is not wrapped in a <p> which removes the extra spacing as well.
Task-2990517
closesodoo/odoo#108434
X-original-commit: b4cf3bcc893e345c25d863c0afaab71bbbfb404c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If only one pricelist is available, it is not necessary to allow the user to click to dropdown the pricelist menu. If only one is available then the pricelist dropdown menu is hidden.
task-3058654
closesodoo/odoo#108418
X-original-commit: caba846362fdc443aa22e1997d7668fa4fd50d6d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, the warning message was below the buttons.
Steps to reproduce:
- Accounting -> Configuration -> Payment Providers
- Select one of them (e.g. Stripe)
- Change the state to 'Test Mode'
- Try to save
Task-ID: 3106197
Related PR: https://github.com/odoo/odoo/pull/107227closesodoo/odoo#108411
X-original-commit: 94f8c4875e3c79709450986ba03e7dee6cb60afe
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce:
1- install any payment acquirer (e.g. stripe)
2- configure the payment acquirer and link it to a journal
3- try to delete the journal
4- the journal can be deleted which will create an internal server
error when this payment acquirer is used
Bug:
There is no restriction on deleting `account.journal` linked to
payment acquirers
Fix:
add a restriction that forces the user to remove the journal from the
payment acquirers first
OPW-3089006
closesodoo/odoo#108403
X-original-commit: 3ec6fe4ab1df3e3368fd06ff0e18a240caf088e5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Note: this bug is not possible to reproduce in 16.0 anymore, since the
Bootstrap 5 update. This commit is however kept as it makes the behavior
more efficient keeping the original fix's diff + it also cleans things
that were not necessary anymore since the "website-in-backend" update
that was made at [1].
Steps to reproduce the bugs (in older versions):
- In edit mode, choose the "contact" header template.
- Drag and drop a table of content snippet on the page.
- Save the page.
- Click on the table of content links.
- Bug => the links are not activated correctly.
The reason of the bug was that the scrollspy offset (calculated against
the header height) was not updating when the header height changed.
We did make a new call to scrollspy at the right time but that had no
effect because we first had to destroy the existing scrollSpy to be able
to make a new call that works.
opw-2951315
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#108223
X-original-commit: edd9d2b3df597786b2db416aed382dc5666623e2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, recruitment models and views were mostly
set inside 'hr_recruitment.py' and 'hr_recruitment_views.xml'
respectively. In order to navigate easily, models are separated
into distinctive files.
closesodoo/odoo#105935
Related: odoo/upgrade#4048
Signed-off-by: Kevin Baptiste <kba@odoo.com>
**Issue:**
- Install crm (to have a form view with phone field).
- Click crm icon.
- Open list view.
- Create a new record.
- Enter title and phone number.
- Click sms button from the right of phone number field.
- On the wizard (dialog), enter a message and send.
- The wizard is closed but (BUG) the form view returns to the state where
a new record is being created.
**Solution:**
The record containing the new sms message is properly created, however
the form view is reloaded with undefined `resId`, thus the form reloaded
as if it is "new".
The simplest fix is to specify the `resId` of the newly created record in
the `model.load` call as proposed in this commit.
closesodoo/odoo#108431
X-original-commit: edaf37eeb9244976ecc6c60aec089f9a2b4e3020
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit (in the case the `custom_mode` is set to `wire_transfer`)
the model tries to find existing bank accounts to compute a pending message
with the necessary information. When bank accounts are not already setup
we end with an incomplete message.
After this commit we can at any point recompute the pending message and it
will be updated with the current bank information.
Task - 2511080
closesodoo/odoo#103903
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This prevents the removal of styles on non-custom buttons, which the
user may have applied to them back when it was possible to apply styles
to non-custom buttons. The removal of styles now only happens when
picking a new link style in the "Style" dropdown, which is what the
removal was intended for.
task-3096806
closesodoo/odoo#108384
X-original-commit: eb4edac560227b46efdcfe958e3b93e0b88def64
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a custom button had a gradient background, clicking in it removed
that gradient. That is because that opened the link tools, which updated
the DOM before having fetched the custom colors.
task-3096806
X-original-commit: c3d22aa0e03588cc8781f015ada9002c6a0a4384
Part-of: odoo/odoo#108384
It made the regex much slower in case of non-match, due to backtracking.
closesodoo/odoo#108046
X-original-commit: 56b1b17d6fdf493368ce219f981f94d9efdc9b7f
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Prior to this commit, the steps block options could not support a column
that was more than nine out of twelve (bootstrap columns) wide.
Steps to reproduce the bug:
- Drop a block step on a page
- Set a width of 10 columns on the first step
- Set a width <= 2 columns on the second step
=> the connector is not well displayed.
task-3033126
closesodoo/odoo#108362
X-original-commit: 9c4e0eaa60ad89140661e3c297ea1b4e22d6faae
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Previously, when restoring service metadata after clearing it, we would
use the patch function instead of an Object.assign. This is probably a
relic of a previous version of the code that used patchWithCleanup, but
in this context it is completely wrong, as we are giving something other
than a string as the patch name and no object at all as the patch value.
closesodoo/odoo#108390
X-original-commit: b83ab5061fe15e69f6c0703baf6f1eec61332f0e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- When clicking on settings we get a crash for an incorrect
CSS selector.
`Caused by: SyntaxError: Element.querySelectorAll: 'footer:not(field footer' is not a valid selector`
This issue happens on outdated version of Firefox (tested on firefox 78)
closesodoo/odoo#108371
X-original-commit: 68b05bc9911f899a2b8a8c3335af90d9ed8129cb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a grouped kanban view with progressbars, click on a progressbar
to filter a column, and then click on the "+" icon of that column
to quick create a record (e.g. in a project). Before this commit,
the buttons ("Add", "Edit" and trash icon) overlapped the bottom
of the card.
This is due to special rules applying when a progressbar filter is
applied. Those rules aim at grouping non filtered out cards on the
top, s.t. the other ones (e.g. a dragged&dropped card) are displayed
below.
It was decided that this grouping isn't really wanted anymore. For
instance, it could lead to weird UX if the filtered column contains
a lot of records, as the dropped one would appear at the bottom,
i.e. would not be visible for the user.
This commit thus simply removes those rules, which fixes the issue.
closesodoo/odoo#108396
X-original-commit: 69fa3654e479f427606d05cdb244fd24225f9eeb
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
When the user exports the note records, an error is raised because the
'__count' key does not exist in the result of the 'read_group' method.
Steps to reproduce:
------------------
- Go to the Notes
- Click on the list view of notes and filter group by Stage.
- Click on the export all button to print the excel report and see the
error.
Expected behavior:
-----------------
The data should be exported in `csv` file.
Current behavior:
----------------
An error is raised when the user wants to export the data.
closesodoo/odoo#108394
X-original-commit: 3bd979421744a11b6f10c95f47cf378720079ffb
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
In Email Marketing's Mail Body, The Powerbox is opened below the cursor,
even when there's not enough space between the cursor line and
the window's bottom. As a result, a part of the Powerbox cannot be seen.
After this commit:
Now, the Powerbox opens itself above the cursor line if it's too close to the
window's bottom.
Task-3037435
closesodoo/odoo#108352
X-original-commit: ba888c39716f0226adce993cb08852e21b0376eb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds a step in the click all test: for each view, enter
and leave Studio, to ensure that the view doesn't crash in Studio.
With the migration of views to owl, a lot of views worked fine, but
crashed when entering Studio. Those issues have been solved now,
and we want to ensure that this no longer happens in the future.
closesodoo/odoo#107992
X-original-commit: d18310bddf0a4f741a6335e5499ab213fb046993
Related: odoo/enterprise#35054
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] introduced a "custom" type of button as the only type of
button whose background color we are allowed to change. But the option
to change any button's background color exists in mass_mailing so we end
up with the same option in two different places. This removes that
previously existing default option.
[1]: https://github.com/odoo/odoo/commit/a010c91b5ee119cf54ed1a68a6ea06b2bc5f3978
task-3096806
closesodoo/odoo#108269
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: website
The fields of a form that are mandatory because of the model they need
to be used in cannot be removed. When such a field is selected, the
remove button displays a tooltip giving this information.
Disabling the overlay button is done by removing the specific class -
which makes the event selector not linked to the button, but also
impacts the applied CSS rules.
This commit adds an `o_disabled` CSS class upon disabling the button.
The tooltip is put on a `span` that wraps the disabled button because
tooltips cannot be shown on disabled elements.
Steps to reproduce:
- Drop a "Form" block.
- Select the "Phone Number" field.
- The overlay's delete icon has a reddish background.
- Select the "Your Email" field.
=> The overlay's delete icon had a dark gray background instead of a
reddish one.
task-2950433
closesodoo/odoo#107864
X-original-commit: ed3acbae6a6b2fe91c948ceeb16a5bdb3fa8f060
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
With recent JS change on "group" the currency symbol was missing. By adding the currency_id field invisible in the arch the problem is solved.
Task-id:3089285
closesodoo/odoo#107106
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
- base.view_base_module_uninstall
- base.base_module_install_review_view_form
- base.base_module_install_review_view_form
were the only 3 views in which a node was set outside the
<form>, <tree>, <kanban>, ... node.
```sql
master-all=# SELECT name FROM ir_ui_view WHERE type != 'qweb' AND inherit_id IS NULL AND arch_db ->> 'en_US' not ilike '<' || type || '%';
name
---------------------------------------
Uninstall module
base.module.install.request.view.form
base.module.install.review.view.form
(3 rows)
```
These were introduced by odoo/odoo#99438.
The goal was to set these warnings on top of the form view,
with no margins for a better UI.
While this serves an understandable purpose,
not having <form> as the root node causes issues:
- First, as seen in the above revision,
it requires to have to specify the view type in the XML data file,
because the view type is guessed from the root node of the view
```diff
<record id="view_base_module_uninstall" model="ir.ui.view">
<field name="name">Uninstall module</field>
<field name="model">base.module.uninstall</field>
+ <field name="type">form</field>
```
- Second, in the view post-processing, some implementations
are based on the root node of the view,
and not having `<form>` as the root node for instance makes
the view not editable, or not pass the `readonly`, `required`
attributes from the Python model.
https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1146-L1147https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1375-L1379
We could use the view type from the model itself,
instead of the root node, to determine the type of the view,
but then you wouldn't be able to use attributes set on the view node,
such as `editable="1"`, to determine if the root/view node is editable
or not.
https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1352
Because the `<form>` node wasn't the root node in the uninstall form view,
the modifiers attributes (`readonly`, `required`) were not passed
from the field python model to the view,
and the Studio fields
`custom_views`, `custom_reports`, `custom_models`, `custom_fields`
were editable in the view, while they shouldn't as those
are readonly computed fields.
A constraint will be added in master, to prevent developers
to create views with as root node something else than the view type.
The constraint is not added in stable 16.0 to avoid to suddenly
raise a constraint exception for modules from the community
and customers in production databases.
closes#107947closesodoo/odoo#108319
X-original-commit: c9dd160242c55dc824d4300635528dc82309f599
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Remove the t-on-click used in form view as it crashes when
opened with studio.
Instead we use a dedicated "<widget/>"
task-3090960
closesodoo/odoo#106241
Related: odoo/enterprise#34235
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
1. Drag and drop the "image - text" snippet.
2. Click on the image => you have a double overlay which appears (one on
the column with handles and one on the image without handles), this is
good, that's what we want: the ability to control the column width but
as the image has options, it should be framed with an overlay too to
indicate what you are editing in the right panel.
3. Hover the column options => good, only the overlay of the column
remains in preview mode (without handles / buttons).
4. Hover the image options => good, only the overlay of the image
remains in preview mode (without handles / buttons).
5. Stop hovering the panel => the double overlay should be restored but
that's not the case: only the column one remains, even though the image
options are still displayed in the panel.
When we introduced the possibility to display 2 overlays at the same
time in this commit [1], we added a loop to search for the overlays to
display since there can now be several.
But in a later commit [2], we added a `break` in this loop, which no
longer allows displaying more than one overlay when necessary.
[1]: https://github.com/odoo/odoo/commit/9bbe5be3fb0d995374a369851df3641979d8e553
[2]: https://github.com/odoo/odoo/commit/806a8db35b5e0e6a461422f5bba7c97180c3ef29
task-2919164
closesodoo/odoo#108334
X-original-commit: ee86f5a94965ce691393f5300bdfb6dc09780b1d
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit: after calling the `init_from_JSON` of the order line,
the `pack_lot_ids` would be changed. It will cause a problem if this
function is called before sending the JSON to the backend or saving it.
The solution is to copy its value and prevent it from changing.
opw-3088922
closesodoo/odoo#108308
X-original-commit: 4f5f5750b05873f0ddce7fe862686202a2725563
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, some tag would not display correctly in the tag list of eLearning
This commit fixes this behavior
closesodoo/odoo#108286
X-original-commit: df1b22f23511ec82687d28a284ab8696fcd2aef4
Related: odoo/enterprise#35091
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Install invoice, go to any sale-order and print it. There are warnings
in the logs for a problem in the wkhtmltopdf subprocess and for 404
page not found for some css assets while rendering the document.
So the first pdf printed is invalid, but as the report is printed the
asset is commited in db and the next print will be valid.
If you use kwkhtmltopdf, as the pdf is not generated (kwkhtmltopdf is
more strict), then you have an error instead of a broken pdf and the
asset is not commit, so you printing is always broken.
Before #104594, the asset was commited at the end even if we had an
error.
closesodoo/odoo#108330
X-original-commit: 0fb8bcbae18027843583304460f1956ef2d2fe51
Signed-off-by: Julien Castiaux <juc@odoo.com>
Purpose of this commit is to add tests to check current behavior of composer
when he is updated with Falsy values :
* template set, with void value for some fields that may reset or not
existing composer values;
* template being set to False, check what happens with composer values
(kept or reset);
This may change in a near future but at least it will be documented.
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#108320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some tests are basically trying some combinations of composer parameters.
Currently only composition mode is a parameter but we will soon add the
batch mode, as it will be dissociated from the mailing mode.
To ease debugging, let us use subTests when possible, even if this creates
some diff due to the new indentation level to add.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#108320
Purpose is to cleanup and add some details in some tests, notably about
default values when using message_post wrappers with either a view or
a template.
Tests with void recordsets are also added to check their current behavior
and try to keep it consistent when cleaning code in a near future.
Add a missing mute logger.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#108320
Before this commit:
Thread details gave information regarding the database
the UID and the URL.
After this commit:
It also informs on the "performance times":
- `qc` = query count
- `qt` = query time
- `pt` = python time. It should in theory be "remaining time", but it won't be use as its acronym `rt` is too ambiguous/confusing
closesodoo/odoo#106610
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
mass_mailing had a special snippet option just for resizing images
horizontally. Since this exists in the website builder as well, there is
no need for a separate snippet with a different behavior for
mass_mailing.
task-2615373
closesodoo/odoo#84061
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Some people are confused because since 'always edit mode'
the alignments of the labels vary according to the groups.
This feature is wanted and the goal is to have the input as close
as possible depending of the largest label of the group (max-width: 150px)
to easily find it when you hover it.
We only keep the aligenment per ´o_inner_group´.
To reinforce this idea of aligned grouped fields, this commit adds
a margin-bottom to separate these groups.
in addition, it allows to better see the groups on mobile.
closesodoo/odoo#108311
X-original-commit: be9e1c666c3bb5aa36fb41a62783c6ecf01aa106
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, labels in a ´o_inner_group´ not wrapped in
a ´o_group´ had a margin-right of 5px while the other labels
have no margin.
it is probably an oversight during the refactoring because margins
are now managed by the grid system.
<group>
<group>
<field name="A"/>
</group>
<group>
[...]
</group>
</group>
<group>
<field name="B"/>
</group>
In this example, inputs of A and B were not aligned because
of the margin-right of label B.
X-original-commit: fb629dc91df1720cb0658d3e9f946a4fda83fbd0
Part-of: odoo/odoo#108311
An error is raised when trying to create sale order lines with tax on a
sale order without any customer (with debug mode enabled)
Steps to reproduce:
1. Install Sales
2. Create a new sale order without any customer
3. Add a new sale order line and a tax to this line
4. An error is raised `Invalid props for component 'TaxGroupComponent':
'currency' is undefined`
Solution:
Make prop `currency` optional (and format the total without any
currency)
Problem:
When trying to render the tax total of a sale order without any
pricelist, an error is raised as the `currency` prop is missing, which
depends on the pricelist
opw-3098020
closesodoo/odoo#108310
X-original-commit: c3acd369976f46e5c987d9d460908f99c6f05b0c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit fixes two things:
- The owl compatibility layer adds an `on` and `off` method on owl's
EventBus so that it can keep being used as it used to in owl 1. To do
this, it needs to keep track of the the callbacks that are attached to
it and by whom. To do this it keeps a Map where the "owners" are keys.
When calling `off` to remove event listeners, we remove the callbacks
but did not remove the owner from the Map, causing the EventBus to
always hold a strong reference to any object that was given as the owner
to the `on` method, preventing the item from being garbage collected.
Objects that do this are typically components, and components hold a
reference to their owl application that contains the entire tree of
components. This was particularly problematic in tests where components
are created and destroyed at a rapid pace.
- The mock websocket creates a MessageChannel so that it can mock the
server side of the websocket, but it never closes that MessageChannel's
MessagePorts, which can cause garbage collection to be slow to happen
[1] (in practice it looks like these are basically never garbage
collected unless closed). This commit registers a cleanup to close the
message ports after the execution of the current test.
[1]: https://html.spec.whatwg.org/dev/web-messaging.html#ports-and-garbage-collectionclosesodoo/odoo#108309
X-original-commit: 4facc396a4e8036592a473002253d5a5daf41a19
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit allows to specify a custom Compiler to be used by the
KanbanRecord of a custom Kanban view (js_class). This is necessary
for the social kanban views. Something similar is already done in
the Form view.
closesodoo/odoo#108221
Related: odoo/enterprise#35065
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In html, tags are case-insensitive. However, owl templates aren't,
as nodes starting with a capital letter are considered as component
nodes (not html). This means that people can use capital letters in
form or kanban archs for html nodes and it should work.
Before this commit, it didn't, because the compiler kept the case
when generating the owl templates. For instance, an arch like
`<form><Div/></form/>` produced the error 'Cannot find the
definition of component "Div"'. This commit fixes the issue.
Part-of: odoo/odoo#108221
Kanban and form archs aren't owl templates. Kanban archs define
a (historically) qweb template ("kanban-box") which is html + some
directives (e.g. t-esc, t-foreach...) and extra tags (field, widget).
Form view archs are html + some extra tags (e.g. group, notebook,
field, widget...).
With the conversion of those views to owl, a door was left open:
one *could* use owl directives (for instance, t-on-click) in archs.
However, we don't want people to do that, as it would tie the archs
in database with js implementation details, which will then limit
the evolution of the js framework.
This commit adds warning when such forbidden directives are detected.
In master, we'll raise errors.
Part-of: odoo/odoo#108221
xO-Tx