The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Since fixes done on the bom overview had to be done in a released
version, no method signature changes could be done, hence the use of
excessive context keys to bypass it.
Changes the signatures so that future work is done on better grounds,
and so that each method explicitely asks for what parameters it needs to
do its work.
closesodoo/odoo#107006
Related: odoo/enterprise#34577
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commit 168cbe66bee7824bdf389de5c6c680342e27bc6d removes fields
with the 'groups' attribute from views when the user is not part
of the groups.
This is the case of product_uom_id in stock_scrap_form_view2,
but the field is mandatory for scrap creation,
therefore we use the unit of measure of the scrapped product
when not provided (as this is the case when uom are not checked).
Task: 2985735
Part-of: odoo/odoo#104062
Following some user brain tests analysis, the following small modifications have been implemented to improve the usability of the app.
* Delete the quick create option of the payment terms
* Change the name of the payment column in the invoice menu
* Removing the tags of the payment column when the state is different of posted
* When only one currency is activated the currency symbol wasn't displayed anymore cause of recent change on the js side with "group", by adding the field currency_id invisible in the arch the problem is solved
closesodoo/odoo#106903
Task-id: 3085423
Related: odoo/enterprise#34558
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
`getInSelection` had a check that depended on `closestElement` returning
an element (and not `undefined` or `null`).
closesodoo/odoo#107061
X-original-commit: 0eeff8266ab1c3bdd15d4587aaf83e299811c3fa
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If you clicked on a pictogram, then previewed various colors for it by
hovering colors in the colorpicker of the toolbar, the toolbar started
flickering uncomfortably. That's because the selection was changed
at every color change, which was unnecessary.
closesodoo/odoo#107041
X-original-commit: f0ff5dc4bdaf5a1704f1af55d46b253e234712a4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If you clicked on a pictogram, then changed its color with the text
colorpicker in the toolbar, the toolbar was replaced with the regular
text toolbar, even though what was being edited was the pictogram.
That's because the information of the last media clicked was lost in the
process.
task-3045166
X-original-commit: fa1c7e68eaa544445621ca7e7e2c647ffe857447
Part-of: odoo/odoo#107041
A commit [1] has recently be added to fix an issue. It actually fixes
another issue too:
1. Create a product P
- Storable
- With one packaging PK for 10 x P
2. Create and confirm a PO
- Order Lines:
- 10 x P with PK
3. On the PO, decrease the quantity of P to 8
Without [1], a return is created for the difference. With [1], the
existing picking is correctly updated.
This commit adds a test to protect the use case.
[1] 20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e
OPW-3027110
closesodoo/odoo#107045
X-original-commit: ccf771d19c5d7b7021c8d0411e11a3f7e9907899
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When decreasing the qty of a SOL, if there is already a packaging
defined, a return will be created for the difference
To reproduce the issue:
1. Create a product P
- Storable
- With one packaging PK for 10 x P
2. Create and confirm a SO
- Order Lines:
- 10 x P with PK
3. On the SO, decrease the quantity of P to 8
Error: a return is created for the difference. Instead, the existing
picking should be updated
At some point, we try to merge the stock moves (`10 x P` and `-2 x P`)
and, to do so, they must have the same `product_packaging_id`:
https://github.com/odoo/odoo/blob/08f53ffa30479cfb452ebaed61b42655eb0e6a95/addons/stock/models/stock_move.py#L808-L813
However, on the SO, when decreasing the quantity, an onchange tries to
find the best packaging. Because the new quantity is not a multiple of
PK, this one is not returned. As a result, the SO has no more packaging
and so does the new stock move (`-2 x P`). Therefore, the stock moves
can not be merged and a new picking (the return) is created.
This commit updates the onchange method so it behaves the same way as
purchase side:
https://github.com/odoo/odoo/blob/20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e/addons/purchase/models/purchase.py#L1224-L1231
In this onchange, the same diff has recently be added for another reason
(see [1])
[1] 20fa7c6f0f5c9cdfae2519ea8d0ff849d7fa3b9e
OPW-3027110
X-original-commit: e92e960a36babf4daf8f79d210c7f53fb376aa74
Part-of: odoo/odoo#107045
Incorporate Ulises Rivadeneyra (UlisesRivadeneyra) as Vauxoo's contributor
I confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr
closesodoo/odoo#107063
X-original-commit: e943bfac0cb1eccf2231ac73b3f14bfced474f5f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Simple refactor in order to make changes to these line trigger the CI/Security
closesodoo/odoo#107032
X-original-commit: 3c215581aa1f8f74f2d9daf1e15f30ee750ec3df
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, when the editor was reset through updateWidget, the
options were not updated.
closesodoo/odoo#107029
X-original-commit: ffd77cf6aee37f8912e1367f8f9ca2f6344e9577
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When converting the list view to owl, the caret indicator for groups in
list view was incorrectly given the extra class `fa-fw` which gives the
icon a fixed-width. This is incompatible with using padding as spacers,
and caused the caret to overlap the group name in nested groups.
This commit fixes that by removing the `fa-fw` class.
closesodoo/odoo#106994
X-original-commit: ff1055ddd07653d156a5887081f3ebe22dcbcae0
Signed-off-by: Samuel Degueldre <sad@odoo.com>
When breaking a page from a Carousel or other slider snippet (eg by
hitting the backspace key at the beginning of a page), the editor's
history gets reverted but ends up applying the `active` class to all
pages. This is due is some way to the `_computeHeights` method of the
slider snippet, which applied the class to all pages to observe their
heights, then put them back in place. It seems in the labyrinth of ticks
the history step somehow started from a place where every page was
active, so we reverted back to that. The point where these classes were
applied should have never been observed in the first place since it's
purely technical. Not observing it fixes the bug.
task-3081259
closesodoo/odoo#106986
X-original-commit: be1d93edcfbd496c22a7c988b4570858a3d06c2c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
[ADD] l10n_ro: Add COA & tax & tax report data
Add the Coa and tax data for the peruvian
localisation (in english with translations)
task-2697901
closesodoo/odoo#104065
Related: odoo/enterprise#33176
Signed-off-by: William André (wan) <wan@odoo.com>
before this commit,
Users are unable to fold/unfold tickets
after this commit,
Users can fold/unfold tickets
task- 3081378
closesodoo/odoo#106992
X-original-commit: ae5df3e46559185773d2826bfbd74335df4d122d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Stepts to reproduce:
Go to Time-off app > configuration > Public Holidays.
Try to create a new holiday and select working hours.
Issue:
It will show up all the working hours available for all companies even
if we are not in that company at the moment.
Solution:
We need to take into account the company for this field in order to only
show the working hours available for this specific company. I've added
to the field the `domain="[('company_id', 'in', [company_id, False])]"`
in order to follow the same behavior as next versions.
This issue affects 15.0 and saas-15.2
opw-3068827
closesodoo/odoo#106981
X-original-commit: 65f2861bf2728a7f9f991c47edc77fc557dfde14
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit description is in three parts: a generic explanation, a real
use case and the solutions
**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
Then, there are two possibilities:
1. If such environment already exists in the environments list of the
transaction, we reuse it:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
2. Else, we create a new one and store it in the transaction:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
It means that its value won't be recomputed unless we delete it
https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
The functions are added in a stack. So, in the execution order, we
will
1. Clear the current environment and the registry
2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
1. E1 is reset (but its lazy properties are not deleted)
2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)
**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316
- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```
**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.
So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.
C1 a40511cd29closesodoo/odoo#106952
X-original-commit: a685f17ec9b0663d3632c903f4f0304d9a58f103
Signed-off-by: Raphael Collet <rco@odoo.com>
The association module was just overwriting a menuitem in membership. This
commit removes the association module and migrates the menuitem change to
membership.
task-3080120
closesodoo/odoo#106472
Related: odoo/upgrade#4075
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose: Use the same labels for the API settings of calendar providers in the
configuration modal as those used in res.config.settings for the same values.
closesodoo/odoo#105500
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
CONTEXT:
emoji_char_field and emoji_text_field
previously used the emoji_dropdown component
along with some utility functions to display
a very limited number of emojis.
As discuss now has a feature-full emoji picker
we aim to take advantage of it by bootstrapping
the picker from the existing components,
using a new javascript model for the
insert/update logic
AFTER THE CHANGE:
Users should be able to select the same emojis
they can use in the discuss chat in all fields
that previously featured an emoji picker.
Such as the livechat bot responses,
social posts, mailing subjects and
the sms message composer.
RELATED CHANGES:
Some tests are updated to use the pyEnv testing
'framework', as we now need to have access to
the messaging service to test these fields.
emoji_mixin is modified to match any emoji
character. The mixin is consolidated into
a single function is actually called anymore.
The text to emoji dict from emojis.js is removed
as it is no longer relevant where it was used.
The fields that used the emoji_mixin will no longer
trigger onChange on inserting an emoji.
However both the input and keydown event are fired
to allow fields using onchange_on_keydown
to trigger the onchange.
The emoji button was turned into an actual button
replacing the original span used in these fields.
This required a different approach to styling as
buttons inherently behave differently than spans.
The button is now moved using an empty div next
to the input and absolute positioning.
Most of the code used for char and text emoji
fields is consolidated into emojis_field_common.
task-3035021
closesodoo/odoo#104799
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Add the Coa and tax data for the peruvian
localisation (in english with translations)
closesodoo/odoo#104073
Task: task-2774275
Related: odoo/enterprise#33183
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, when resizing window so that chatter swap
position, the text content of message disappeared.
This happens because OWL re-render the message view as completely
different DOM elements, while modeling in discuss code kept
identity of the MessageView. As a result, the message text content
was unchanged therefore it was not updated in the DOM, thus staying
blank.
This commit fixes the issue by enforcing setting the message text
content in DOM whenever the value is empty in DOM but the message
has logically some text content.
closesodoo/odoo#106978
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since [1] when the search bar was refactored, images can be displayed in
the autocomplete results, and fallback icons are displayed instead of
images for records that have no images.
However, if no module that participates in the results provides actual
images, then the fallback icons are not displayed at all.
This commit makes the fallback icons displayed only based on the "Image"
toggle option of the search bar.
It also disables the hidden display options and enables the visible
ones.
Steps to reproduce:
- Do NOT install website_sale (which is currently the only module that
provides autocomplete results with images).
- Drop a "Search" block.
- Save.
- Type a single letter in the search box. (e.g. "a")
=> Autocomplete results were displayed without their icons.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2951026
closesodoo/odoo#106953
X-original-commit: 4eecba4c8f5327fd1a137a8d88574c2b6a5eda05
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The tooling has been introduce in later version of odoo.
It is a problem when somebody switches to older branches without
disabling the tooling as it would then try to commit the tooling config
files.
We just add a few lines in the gitignore to prevent this issue.
closesodoo/odoo#106951
X-original-commit: b469295c884026caea1b7779e7ffb778e7a08ab3
Related: odoo/enterprise#34552
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce:
1- install ecommerce - payment_stripe
2- configure stripe testing credentials
3- edit main currency to have more decimal places (assume 4 instead
of 2 for USD)
4- add product p to cart (assume p.price = 100 USD)
5- checkout with stripe
6- the price is 10,000 USD instead of 100 USD
Bug:
Stripe expects the amount in the smallest unit possible for the
currency. https://stripe.com/docs/currencies#zero-decimal
This differs from a currency to another according to
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions
`to_minor_currency_units` uses the decimal places of the currency by
default which will produce wrong values
Fix:
use currency exponent table built from
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions
default behavior (for a currency that is not available) is not changed
OPW-3058173
closesodoo/odoo#106936
X-original-commit: 703ed2b4e162ff0a7b621e3cf8b92b8eb7fddff8
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Previously, _intervals_duration (called by _compute_duration)
sometimes loose the last mrp.workcenter.productivity.
A fix has been made.
First, mrp.workcenter.productivity.loss _convert_to_duration
calculates according to the loss type, we have to take that in account.
Second, mrp.workcenter.productivity _close badly generates
performance timers.
For example, test_mrp_employee_analytic_account generated
- productive for 1st employee from 10:00 to 11:00
- performance for 2nd employee from 10:00 to 11:00
- performance for 2nd employee from 11:00 to 11:00 (! duration = 0)
Now, the timers are
- productive for 1st employee from 10:00 to 11:00
- productive for 2nd employee from 10:00 to 11:00
which is correct.
closesodoo/odoo#106908
Task: 2985735
X-original-commit: 8638ec145ab83e4afafa39a5c9e987e8d772bfd1
Related: odoo/enterprise#34533
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Fix workorder times problems:
- sum in workorders list view
(displays numeric value rather than mins:secs)
- timers sometimes starts at -00:01
- almost all tablet view actions reset the timer (click burger, ...)
- clicking pause stops the timer at the next second
- seconds are lost in employee timers
Task: 2985735
X-original-commit: 7dceef12771890f9fb9fa554e70414c622053ced
Part-of: odoo/odoo#106908
This commit adds tracking to the "plan to change car" field in res.partner.
task-3086287
closesodoo/odoo#106845
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Add an ACL to allow read-only access for basic users to the workcenter
capacities. This avoids an error in the bom overview opening with a
simple MRP "user".
closesodoo/odoo#106935
X-original-commit: 3095eb4d39711260b483771f04f0904d7f7a245a
Related: odoo/enterprise#34545
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Take the following BoM :
Final_product
Semi_final_1 (Subcontracted)
Component_1 (Dropshipped to subcontractor)
Semi_final_2 (Manufactured by us)
Component_1 (Bought then put in stock)
Component_1 is used in both semi_finals, but in different contexts. For
Semi_final_1, it's directly dropshipped to the subcontractor, while for
Semi_final_2 we resupply our stock and then use it from there.
Problem is, since both components are the same, there was no distinction
made when fetching the data for the resupply methods. So if the first
case encountered was the dropship (like here), then for Semi_final_2 the
dropship would be used as well, while we're not in a subcontracting
context anymore.
Now we consider the parent_bom when fetching and storing the resupply
data, as different boms can have different contexts.
Part of task-2985735
X-original-commit: 9ceb6b4f5996f962689ea671ea79ba81deeee763
Part-of: odoo/odoo#106935
Before this commit, the rules were checked related to the currently
selected warehouse. Doing this didn't allow to check the subcontracted
locations for their related rules (like Drophip subcontractor on order).
The point here is that when no rules are found within the warehouse, it
checks the subcontracted location of the parent if the parent is
subcontracted itself.
Part of task-2985735
X-original-commit: feeef868093042ae4cb788d513c02244b8c36623
Part-of: odoo/odoo#106935
Before this, when working on a bom with variants, when checking the
parent from the component / child_bom, it would always take the first
variant since it used the bom's product_template.
This could lead to incorrect data when working with subcontracting, as
when another variant from the first would be selected, when fetching
quantities no parent info would be found as it would seek info from the
first variant of the bom instead of the correct one.
By doing this, we can now have the right variant and fetch the right
informations.
Part of task-2985735
X-original-commit: c855038c73e2c964ef78b41090c35e3a07d30f9b
Part-of: odoo/odoo#106935
Since the pager div doesn't appear anymore in the DOM when it would be
empty, the filters buttons (warehouse and display) would be pushed back
to the end of the flex div.
Part of task-2985735
X-original-commit: 4ee3875a6d6faf5563c720fa399eca5b4a1d0e4f
Part-of: odoo/odoo#106935
The group `“base.group_user”` is added in the view for the field
`standard_price` while it is already set on the python side:
https://github.com/odoo/odoo/blob/16.0/addons/product/models/product_template.py#L76
this causes an issue in the case of a product with variants,
the invisible attrs is ignored, the `standard_price` and
`uom_name` field are hidden, but the label will still be displayed
opw-3076827
closesodoo/odoo#106925
X-original-commit: 206e88b0ad9fdb6e1767c93b3eca8feeecddd3da
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When the contract has a working schedule different
from the employee's, a red triangle appears with a tooltip
explaining the reason. That tooltip was implemented in the
arch view using data-tooltip, which is not intended.
This commit adds an owl widget replacing that issue.
In order to test that tooltip warning, it's only needed
to go on any running contract and change the resource_calendar
so it's different to the one on the employee's page.
Same process on the employee form.
closesodoo/odoo#106760
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce the bug:
- Enable “package” option in the settings
- Create a storable product “P1”
- update the stock to 100
- Create a picking:
- product : P1
- Qty: 1
- operation type: delivery
- go to additional info > add a carrier
- Mark as todo
- update the qty done to 1
- Create a second picking with the same steps
- Create a batch picking:
- Add the picking 1 and 2
- Confirm
- Go to “Detailed operation” tab
- Click on “Put in pack”
- add a “Delivery packaging”
- Save
- Click a second time on “Put in pack”
- Select the same “Delivery packaging”
- Save
Problem:
Traceback is triggered: “tuple index out of range”
When the “Put in pack” button is clicked, the “action_put_in_pack”
function is called, the move_line_ids which has no package or with
a 0 quantity done are filtered, in this case the 2nd move_line with
the product “P2” will be used, but the `_pre_put_in_pack_hook` function
is not called with its picking:
https://github.com/odoo/odoo/blob/14.0/addons/stock_picking_batch/models/stock_picking_batch.py#L229
But rather with the first picking, it will have no move_line because the
first move_line already has a quantity done at 1 and a package.
So we try to get a record in an empty array:
https://github.com/odoo/odoo/blob/14.0/addons/stock/models/stock_picking.py#L1312
opw-3067921
closesodoo/odoo#106943
X-original-commit: 1b6208a2db00ed387bcd0833787fa05416a426ba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In the 2022 Tax report, box 16: 'Total de la TVA brute due (lignes 08 à 5B)'.
The formula is missing tags P1, P2, I1 to I6.
opw-3036679
closesodoo/odoo#106948
X-original-commit: 67a4538e4c9ff3c2df895dfd43843154af728997
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
