This commit fixes some wrong usage of the bootstrap class `col` & `row`:
- POS: Missing the child `col` on `row` parent;
- Survey: Using the class `col` to center the node on the parent div;
closesodoo/odoo#101046
X-original-commit: acacf52d40a41b53aa78967748602cb3b1e62261
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the inputs (radio, check and select types) on
`focus` state wasn't visible due to the override rules in Bootstrap:
```scss
/* Example of rule for checkbox */
.form-check-input:focus {
border-color: $form-check-input-focus-border;
}
/* Default config of Bootstrap 5 */
$component-active-bg: $primary !default;
$input-focus-border-color: tint-color($component-active-bg, 50%) !default;
$form-check-input-focus-border: $input-focus-border-color !default;
/* Our override in Odoo */
$component-active-bg: $gray-200 !default;
```
This commit, sets the `$o-brand-primary` color (`#71639e` in community,
`#017e84` in enterprise) on the border in focused state.
Note:
before Bootstrap 5, this bug was not present as custom-checkbox was a
custom pseudo-element (`::before`), and so it was not possible to be on
a `focus` state on this pseudo-element.
closesodoo/odoo#101044
X-original-commit: fba258e738d6b629bb79fb5d7d9c9585733d72b1
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit properly removes the Many2ManyTagsField and
Many2ManyTagsAvatarField's placeholder when at least one tag has been
selected.
Steps to reproduce:
- In Contacts, open a partner's form view
- Edit and set at least one "tag"
- The placeholder is present next to the selected tags
Note: the placeholder was already present in previous versions.
Reported by FP.
closesodoo/odoo#101042
X-original-commit: 5976e19a31b9b0edaefc1079541514810d12b240
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closesodoo/odoo#101012
X-original-commit: 9ec7aa9b89bc929af15473d0cc29084fd831cf94
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, when exiting a record in any way, the validity of
each of the fields was checked, even if not dirty. This means that the
user would be locked on a required field if that field got an invalid
value from the server, even with no given input.
In this commit, switching the mode on a record ("readonly" | "edit")
will not go through validation if the record was not dirty.
closesodoo/odoo#101000
X-original-commit: 8a8241503e41486e79ca19f9ca16f413cfabb08b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When generating an invoice for a SO with 2 SOL that have a timesheet service
(1 SOL is timesheeted in August, the other is timesheeted in September) and
we request the invoice for the period of August only, the SOL for September
is incorrectly set to state "Nothing to Invoice", instead of staying in
state "To Invoice".
This is due to the fact that when we inspect the SOL to invoice, those that
are not in the domain (here the SOL in September is not in the time domain
of August), we set it's qty_to_invoice to 0, so it doesn't get invoiced, but
this is a computed field, which sets the line invoice_state to "Nothing to
invoice".
The proposed fix is to reset the invoice_state of the lines that are not validated by the domain to the state before setting the field qty_to_invoice to 0.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- master
opw-2969641
closesodoo/odoo#100978
X-original-commit: 50b81adb3ea13db33bf1375b7038b6cc3546ec86
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
- In `unlink`, since https://github.com/odoo/odoo/pull/66938
modified is called on self for each batch of 1_000.
But it should be called on the batched records.
- In `write`, remove useless `records_to_inverse`
(there from ORM refactor but never used)
- make `_modified_triggers` more deterministic by
changing a `set` into `OrderedSet`.
closesodoo/odoo#100472
Signed-off-by: Raphael Collet <rco@odoo.com>
So far the vat_label was missing in res_country_data.xml.
This defines the official name for the local Tax ID (called "RUC").
closesodoo/odoo#100650
X-original-commit: 53b0ff01535c10d31102e9087d9e5196fa261630
Signed-off-by: Laurent Smet <las@odoo.com>
Longpolling port is replaced with gevent port and is deprecated
This commit avoid saving the value.
Not really usefull but when saved the value was None leadind to an error
when casting to int. The default value should be an int.
closesodoo/odoo#100991
X-original-commit: adac9a9ceaa173c0181a4fc57d0ea83b7a37fc71
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
They tend to come in the way of very obvious things in the UI, repeat
the same stuff that the label, etc.
Titles attributes are not good for a11y, so if needed I prefer replacing
them with an aria-label which:
- doesn't mess up the UI
- works properly with screen readers
I've kept them on nodes that have no text (e.g. icons), otherwise
they're not needed - text needs not be labelled.
closesodoo/odoo#100990
X-original-commit: 1c52c649f99d831de98d349d1ffbc6abc95a93ae
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Currently, When we create an invoice from a sale order containing some notes or sections.
The analytic account from the sale order is set on the invoice/move line.
During the creation of analytic lines, a line is created from the section/note line.
This commit makes no analytic line is created for section/notes.
closesodoo/odoo#100989
X-original-commit: a1bff32113bb0b551cd62efea5030c8f3bd4d1de
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
one with values:
- Product: Table Top
- Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
finish time) even though its expected duration is 2 hours
Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)
Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning
opw-2893622
closesodoo/odoo#100988
X-original-commit: 2515482d5a706c65a7d8e27028f43987f17e6e67
Related: odoo/enterprise#31720
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, in a list view, the context set on a m2o field
is not used when you edit the field to create a new record.
How:
- Go to a list view with a m2o field containing a context
<field name="m2o" context={"test":1}/>
- Edit the field the m2o field
- Click on "Create ..."
Before this commit:
The name_create method call does not contain the context defined
on the <field/>
After this commit:
The call to the name_create method contains the context defined
on the <field/>
closesodoo/odoo#100987
X-original-commit: dd1e7fab585ed5a691456632c20097ce443d9d69
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit moves the inline handlers of the `useSortable` hook
calls in the list and kanban renderers to proper class methods.
This allows said handlers to be overridden in child classes.
closesodoo/odoo#100986
X-original-commit: ec5ab1d389a0bdfb37c8b2c6766b6be1330085a7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit implements the "name_get" method in the sample server.
This is required for m2o fields with the "always_reload" option.
How to reproduce?
go to an empty list view with sample="1" containing a m2o field with the
"always_reload" option
Before this commit
We have a crash because the "name_get" method does not exist.
After this commit
The view is rendered correctly with the sample data.
closesodoo/odoo#100985
X-original-commit: 4e53f92caf2527b15439eae041fcd238e2ed8145
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The placeholders were rendered as empty string in the web version of the
mailing (accessed through the "view online" link in the email). This fixes the
problem.
Technical note: we cannot use mail_mail.body_html (which contains already the
rendered placeholder for the specific user) as it is marked for deletion so we
render it from mailing_mailing.body_html.
Task-2954282
closesodoo/odoo#100984
X-original-commit: 6b2d5db762ef198e9f07af95116c166b027eb383
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Indonesia officially added new province. Papua Selatan, Papua Tengah, Papua Pegunungan.
closesodoo/odoo#100980
X-original-commit: 9d047bfac876f814f46cf212d2be44614a8e7a71
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The move line list js has a set thread method that tries to
get the move_id from the list view.
But in the list view, the move id was now missing so it
couldn't find it when a filter on journal entry was set.
This adds it again so that the code can get the information
again.
closesodoo/odoo#100974
X-original-commit: 8857d31bfa6f2e330d296ab6f3ed9223e228f54e
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
A crash would occur when creating new records as the code did not take
into account the possibility of having empty "base" data.
closesodoo/odoo#100973
X-original-commit: 497db878fa3f9303ce33035d5737352289c4f97d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Currently, if we create an activity for user other than logged in one and
create a calendar event from the activity, it automatically changes the
attendee on the event and re-assigns the activity to the logged in user
instead of the one originally assigned to the activity during creation.
It happens because default attendees are not passed while creating the
event from activity. ALso, when editing the calendar event, the sync
mechanism changes the activity user to the organizer of the event, which
by default is logged in user.
This commit improves the behavior by passing the appropriate default
values so that the calendar attendees and organizer matches with the
user to whom the activity is assigned initially.
task-2920631
closesodoo/odoo#96943
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit
The method `updateValue` was updating value constantly
because `value` was a string and `this.props.value` a Markup.
Now
Update only when necessary
closesodoo/odoo#100965
X-original-commit: 45d4ac14f65c53dcde56592715d50169bde116ad
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit adapts the x2many as first notebook tab's child selector to
the DOM of its OWL implementation, restoring the correct padding in this
case.
Steps to reproduce:
- Open Product form view
- Select the Variants notebook's tab
- Tab shouldn't have padding when the first child is a one2many
closesodoo/odoo#100912
X-original-commit: 74875dcc0b84236c0911b117666fc6deb41ed432
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
After this commit, fields from models framework are stringified to
follow the presentation ModelName/fieldName.
Task-2992286
closesodoo/odoo#100845
X-original-commit: d645bf2c708f67ff27d004b79754926f3086c58b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps to reproduce:
- in Barcode > Inventory Adjustment
In the quantities add a decimal numpad
Issue:
Traceback
Cause:
The field is from type=number. This kind of field does not accept methods such `selectionStart()` or `selectionEnd` which causes an error: https://html.spec.whatwg.org/multipage/input.html#do-not-apply
Solution:
When of type=number, just return.
On Chrome, numpad won't be possible for regions such as Portugese - BR. They would have to use the keyboard key `period`, code '.' in order to be able to put a decimal via the keyboard.
In Firefox, HTML is parsing the input correctly if the browser settings are set to the right localization. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#localization
opw-2956481
closesodoo/odoo#100953
X-original-commit: d95fbd80f63efbb47c9635e299f6ac417c5cb4c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Currently the web.ReportAction component instantiates an iframe with 100vh of
height, while it should be instantiating the iframe with h-100. It assumed the
only component that would be rendered was the iframe, but we also need to take
into account the control panel and etc.
Also, the ReportAction component wasn't taking into account the height of the
control panel to set the height of the `.o_content` div. This also caused the
iframe to be rendered with the wrong height. This commit fixes this by adding
a flexbox column wrapper before the layout component.
closesodoo/odoo#100938
X-original-commit: 26cb2e1f659597311a06e46a84d7a0a9c3df6f74
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Before this commit, when scrolling in the emoji grid and there's still
2 rows of emojis before a category section, this category was
mistakenly considered as active.
This commit fixes the issue, so that the category is considered active
only when the 1st visible row is in this category.
Task-2992589
closesodoo/odoo#100934
X-original-commit: 5eea0b5480f1e45b0b05bedc21689d35178490b7
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since commit odoo/odoo@0afe6fbda5
the `$card-cap-bg` was set to `white` to avoid inconsistencies in the
design. But the original value is `rgba($black, .03)` (3% of opacity of
black, almost transparent), this allows to customize the card color
using the utilities classes (e.g. `bg-danger`) but since the header of
the card is not more transparent, this behaviour is not working anymore.
This fix restore the original behaviour to avoid to break Bootstrap.
Steps to reproduce:
* Make an Odoo database without demo data
* Install an app
* Go to Settings
* Click on "Load demo data"
* A modal is open with a Bootstrap Card
* The title of the card has a withe background, not a reddish one => BUG
closesodoo/odoo#100932
X-original-commit: a1c7e3ac1b42beeb5de94307fb1bb5f09c869167
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
What is done in start should be undone in the destroy.
closesodoo/odoo#100904
X-original-commit: a221342ca18db892153bbf4139c0bee7cd1e9bde
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The notification_alert component can now be registered as a view_widgets directly
closesodoo/odoo#100898
X-original-commit: 4f91758d1aefb6e459ccf02220bf4cf27f3a2ff2
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit makes all sorts unconditional, which would allow us to get
rid of the functions that wrap the sorting rules and use arrays directly
instead.
This will allow us to lighten the syntax and to perform some
optimizations in subsequent PRs.
Task-2992581.
closesodoo/odoo#100895
X-original-commit: 4d15ca0f6883fb089e8d7514c4e639b86cedbd45
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since the merge of Bootstrap 5, some data attributes was non converted
to the new syntax for Bootstrap 5 (data-interval -> data-bs-interval).
closesodoo/odoo#100935
X-original-commit: bb9f7542b9dd481c363b593aa97d4a6f2d5ecd1f
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
In mass mailing, a button allows you to see selected records. In some case the
displayed view of selected records allows to alter records (ex.: cancel
attendee in event) which then affects the number of selected records. This fix
forces the recompute of the number of selected record when closing the view so
that it takes into account the potential modification done in the selected
record view.
In mass mailing, in the selected records view, the button is called "cancel"
but any action performed in the modal will still be applied. This fix renames
that button to "close".
Task-2921762
closesodoo/odoo#100933
X-original-commit: be4e409ec1c23f64e11796b05643e424a93aba9e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The method `_clean_leave_responsible_users` is also called from the
write method in hr.employee, however not anyone can remove users from
groups.
Fix of the fix in odoo/odoo#100591closesodoo/odoo#100923
X-original-commit: 129e4799b04210f107185ba96b5c1845d943cf8b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit avoid to have a dict by reference that will be global.
Now get_default_session return a new dict each time for the context key.
From this way the session.context['lang'] is not shared between several
users on the same worker.
To reproduce the bug, restart the server with 2 workers, make request in
lang A on these 2 workers. DEFAULT_SESSION['context']['lang'] now is set
to this lang A.
Now, make request to an url without lang in path and without cookies and
withtout session, you should be redirected to lang B (preferred lang
from the request header) but you will be redirect to lang A due to the
dict session.context that is shared for the worker...
When we initialize the new Session, we get the wrong lang A as value for
context.lang, so we don't recompute the expected lang for the end user.
X-original-commit: 62179de74862210fe2a055d15b367b1850c24263
fwd-port of #100102closesodoo/odoo#100910
X-original-commit: 42e46b2d89dde276f796b980f29e33cc216e7cb2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Steps to reproduce the bug:
- create a new product “p1”
- Create a purchase order with “P1” → confirm it
- Click on “Purchase history”
Problem:
No purchase order is displayed for this product, whereas we have a
confirmed PO.
Because the partner id is formatted as a string and added to the domain,
so when the `web_search_read` function is executed, it will return an
empty result because the id is supposed to be a number instead of a
string: https://github .com/odoo/odoo/blob/master/addons/web/models/models.py#L62
Solution:
The filter on the vendor can be removed because it's already added when
calling the action: https://github.com/odoo/odoo/blob/678bc958fafd5502a61ce54069b13160ad37d2d4/addons/purchase/models/purchase.py# L1240
opw-2976152
closesodoo/odoo#100892
X-original-commit: 9431adc5bfce525bd3a9ec4c3f7215f2ee312841
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Replace the old "shortcuts" cheat sheet with opening the command
palette, which displays these shortcuts (and all of them, not just the
common ones) and also will display a tip regarding how to make the
shortcuts overlay appear.
closesodoo/odoo#100941
X-original-commit: e2625d7bc0c10d7b96912e06bcffe7074cfe6962
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit ports the custom implementation of the view form for the chatbot
scripts to the new OWL framework.
The goal is the same as the base customization, which is mainly to correctly
assign a sequence to every step and save the form in-between every new steps.
This is necessary to allow the end-user to easily configure its script, since
steps can depend on each other.
More details in https://github.com/odoo/odoo/pull/84000
In addition, we slightly adapt the CRM bridge to enable no_open for the sales
team field.
This avoids issues when the user tries to open modals on top of modals.
Task-2981969
closesodoo/odoo#100940
X-original-commit: 68d5da02642d22551603e4c6b5583755b2f4fc2d
Related: odoo/enterprise#31688
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit simply exports the 'X2ManyFieldDialog' component from its
definition file.
That way it can be properly extended / patched when necessary.
Task-2981969
X-original-commit: 881d8ef998b8a98b89ccbab93dcf1ed76ca1193b
Part-of: odoo/odoo#100940
The useChildRef (used with the useForwardRefToParent hook) allows
to retrieve, from a parent component, a t-ref from a child.
Consider the following scenario:
- have a parent calling useChildRef
- have a conditional (with t-if) child calling useForwardRefToParent
- in the initial rendering, the child is displayed
-> ref.el points to the correct html element
- re-render s.t. the child is no longer displayed
-> ref.el is null, because the referenced element doesn't exist
- re-render s.t. the child is displayed again
Before this commit, at this point, ref.el will always be null,
even though the corresponding element comes back into the DOM. This
commit fixes the issue by correctly updating the ref, each time the
useForwardRefToParent hook is called.
closesodoo/odoo#100937
X-original-commit: 78d39c79993d1d63c189164f8104e5a3c90f2efd
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The domain was looking for a company with the name 'company_id' instead
of a company with the id in the field company_id.
closesodoo/odoo#100939
X-original-commit: b2d69fbdc48abde082bf7685b112796933921eb2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The purpose of the task is twofold:
1. Remove empty lines in the company address.
Until now, the address format was fixed, which could
lead to empty lines if one or more field(s) were missing.
We are now removing empty fields to avoid that.
2. Make sure the external report layout is configured
before generating the PDF.
This will ensure that the company data will appear
in the file. If no layout is defined,
it would not be shown.
task-2834517
closesodoo/odoo#100936
X-original-commit: f36bb6acdacaaba26afdd8f62c48fd2c8784d1e1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- Switch to debug mode
- Go to calendar
- Create an allday event in the future named test
- Add an attendee with an email address
- Save
- Go to Settings > Technical > Email > Emails
Two emails have been sent:
* Invitation to test
* test: Date updated
Cause of the issue:
The method `_inverse_dates` is called when creating an event,
triggering a write on the start field.
This then causes an update email to be sent
Solution:
Add a context key and don't send the update email if it is present
opw-2841276
closesodoo/odoo#100925
X-original-commit: d1e55727d010de2cd05bd2871b60d0e95caaaebf
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
User portal creates SO and proceeds checkout by paypal. The system will automatically confirm SO and generate PO. Since the PO is created by the user portal, the user portal can see the PO.
closesodoo/odoo#100920
X-original-commit: a4a062301a1ebd06057aa9468c3734dab2441814
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit restores the almost-full (aka. 90%) width for the grouped
kanban's column (which use .o_kanban_small_column) on smaller screens.
As a reminder, to goal of this specific size is to give as much space as
possible for the column's cards *but* also showing a hint to the
previous/next columns.
Steps to reproduce:
- Open CRM grouped kanban on a mobile-like screen size
- Columns' width is not properly set (too small)
closesodoo/odoo#100911
X-original-commit: 6b60d332a0207342fec0a3a32af8ed30a8a73d91
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
When installing l10n_mx, a error occurs
Traceback (most recent call last):
File "/data/build/odoo/odoo/service/server.py", line 1289, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-15>", line 2, in new
File "/data/build/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/data/build/odoo/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/data/build/odoo/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/data/build/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/data/build/odoo/odoo/modules/loading.py", line 206, in load_module_graph
registry.setup_models(cr)
File "/data/build/odoo/odoo/modules/registry.py", line 289, in setup_models
model._setup_fields()
File "/data/build/odoo/odoo/models.py", line 3294, in _setup_fields
field.setup(self)
File "/data/build/odoo/odoo/fields.py", line 512, in setup
self.setup_nonrelated(model)
File "/data/build/odoo/odoo/fields.py", line 4524, in setup_nonrelated
m2m = model.pool._m2m
AttributeError: 'Registry' object has no attribute '_m2m'
Since #99438 hr is sintalled automatically
This means that when doing a -i l10n_mx, hr is installed too
hr will conditionnaly call a button_immediate_install in this case.
What's going on after that: It's a mess
button_immediate_install will create another registry
This registry will be present on some models that will ne used later
by the initial registry creating the missing _m2m case
For the record, here are some of the strange and key element during
the install
2022-09-21 16:31:27,691 2579263 INFO test_mx odoo.modules.loading: loading 1 modules...
2022-09-21 16:31:27,691 2579263 INFO test_mx odoo.modules.loading: Loading module base (1/1)
...
2022-09-21 16:31:36,222 2579263 INFO test_mx odoo.modules.loading: Module base loaded in 8.53s, 8902 queries (+8902 other)
2022-09-21 16:31:36,222 2579263 INFO test_mx odoo.modules.loading: 1 modules loaded in 8.53s, 8902 queries (+8902 extra)
2022-09-21 16:31:36,240 2579263 INFO test_mx odoo.modules.loading: updating modules list
2022-09-21 16:31:36,241 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.update_list on [] to user __system__ #1 via n/a
2022-09-21 16:31:36,943 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Mexico - Accounting'] to user __system__ #1 via n/a
...
2022-09-21 16:31:49,775 2579263 INFO test_mx odoo.modules.loading: Loading module base_install_request (26/78)
...
2022-09-21 16:31:50,043 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Project', 'Email Marketing', 'Employees', 'Knowledge', 'Sign', 'Planning', 'Appointments', 'Surveys'] to user __system__ #1 via n/a
2022-09-21 16:31:50,167 2579263 INFO test_mx odoo.modules.loading: Module base_install_request loaded in 0.39s, 228 queries (+228 other)
...
2022-09-21 16:32:10,816 2579263 INFO test_mx odoo.modules.loading: Loading module l10n_mx (55/78)
...
2022-09-21 16:32:17,618 2579263 INFO test_mx odoo.modules.loading: Module l10n_mx loaded in 6.80s, 4302 queries (+4332 other)
...
2022-09-21 16:32:50,371 2579263 INFO test_mx odoo.modules.loading: Loading module hr (35/112)
2022-09-21 16:32:57,594 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_immediate_install on ['Employees - Mexico'] to user __system__ #1 via n/a
2022-09-21 16:32:57,594 2579263 INFO test_mx odoo.addons.base.models.ir_module: User #1 triggered module installation
2022-09-21 16:32:57,595 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Employees - Mexico'] to user __system__ #1 via n/a
...
2022-09-21 16:32:58,558 2579263 ERROR test_mx odoo.modules.registry: Creating Registry <odoo.modules.registry.Registry object at 0x7f02cc0e8130>
Stack (most recent call last):
File "/home/xdo/osrc/master/odoo/odoo-bin", line 8, in <module>
odoo.cli.main()
File "/home/xdo/osrc/master/odoo/odoo/cli/command.py", line 56, in main
o.run(args)
File "/home/xdo/osrc/master/odoo/odoo/cli/server.py", line 179, in run
main(args)
File "/home/xdo/osrc/master/odoo/odoo/cli/server.py", line 173, in main
rc = odoo.service.server.start(preload=preload, stop=stop)
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1391, in start
rc = server.run(preload, stop)
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 570, in run
rc = preload_registries(preload)
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1289, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-15>", line 2, in new
File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 248, in load_module_graph
getattr(py_module, post_init)(cr, registry)
File "/home/xdo/osrc/master/odoo/addons/hr/__init__.py", line 19, in _install_hr_localization
l10n_mx.button_immediate_install()
File "<decorator-gen-74>", line 2, in button_immediate_install
File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 75, in check_and_log
return method(self, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 486, in button_immediate_install
return self._button_immediate_function(type(self).button_install)
File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 607, in _button_immediate_function
registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "<decorator-gen-15>", line 2, in new
File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 79, in new
registry.init(db_name)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 115, in init
_logger.error(self, stack_info=True)
2022-09-21 16:32:58,580 2579263 INFO test_mx odoo.modules.loading: loading 1 modules...
2022-09-21 16:32:58,581 2579263 INFO test_mx odoo.modules.loading: Loading module base (1/1)
...
2022-09-21 16:33:35,294 2579263 INFO test_mx odoo.modules.loading: Loading module base_install_request (30/85)
...
2022-09-21 16:33:35,745 2579263 INFO test_mx odoo.modules.loading: Module base_install_request loaded in 0.45s, 131 queries (+131 other)
...
2022-09-21 16:34:05,789 2579263 INFO test_mx odoo.modules.loading: Loading module l10n_mx (62/85)
...
2022-09-21 16:34:28,497 2579263 INFO test_mx odoo.modules.loading: Loading module hr (35/113)
...
2022-09-21 16:34:32,067 2579263 INFO test_mx odoo.modules.loading: Module hr loaded in 3.57s, 4092 queries (+4092 other)
2022-09-21 16:34:32,067 2579263 INFO test_mx odoo.modules.loading: Loading module link_tracker (37/113)
...
2022-09-21 16:34:32,690 2579263 INFO test_mx odoo.modules.loading: Module link_tracker loaded in 0.62s, 267 queries (+267 other)
...
2022-09-21 16:35:04,063 2579263 INFO test_mx odoo.modules.loading: Modules loaded.
2022-09-21 16:35:04,068 2579263 INFO test_mx odoo.modules.registry: Registry loaded in 125.514s
2022-09-21 16:35:04,068 2579263 INFO test_mx odoo.addons.base.models.ir_module: getting next ir.actions.todo()
2022-09-21 16:35:04,071 2579263 INFO test_mx odoo.addons.base.models.ir_module: next action is "Open Menu"
2022-09-21 16:35:04,094 2579263 INFO test_mx odoo.modules.loading: Module hr loaded in 133.72s, 4344 queries (+81420 other)
...
2022-09-21 16:35:04,094 2579263 INFO test_mx odoo.modules.loading: Loading module link_tracker (37/112)
2022-09-21 16:35:04,163 2579263 ERROR test_mx odoo.modules.registry:
setuping model: ir.model.fields()
registry on model: <odoo.modules.registry.Registry object at 0x7f02cc0e8130>
registry calling setup_models: <odoo.modules.registry.Registry object at 0x7f02e92399d0>
2022-09-21 16:35:04,164 2579263 WARNING test_mx odoo.modules.loading: Transient module states were reset
2022-09-21 16:35:04,165 2579263 ERROR test_mx odoo.modules.registry: Failed to load registry
2022-09-21 16:35:04,165 2579263 CRITICAL test_mx odoo.service.server: Failed to initialize database `test_mx`.
Traceback (most recent call last):
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1289, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-15>", line 2, in new
File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 206, in load_module_graph
registry.setup_models(cr)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 293, in setup_models
model._setup_fields()
File "/home/xdo/osrc/master/odoo/odoo/models.py", line 3294, in _setup_fields
field.setup(self)
File "/home/xdo/osrc/master/odoo/odoo/fields.py", line 512, in setup
self.setup_nonrelated(model)
File "/home/xdo/osrc/master/odoo/odoo/fields.py", line 4524, in setup_nonrelated
m2m = model.pool._m2m
AttributeError: 'Registry' object has no attribute '_m2m'
Naive fix here: use button_install instead of button_immediate_install
(not even sure this is 100% correct)
All calls to button_immediate_install should be fixed maybe to avoid
a registryloadingception
closesodoo/odoo#100909
X-original-commit: 919c1f362b1c26dbd04b0501c4d63e2929fb8df4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Romain Estievenart