Move it in an external view to be able to place it at a different
location depending on the header template.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: 010efaeb6d96f156eced62dfd7d842f1d588698f
Move it in an external view to be able to place it at a different
location depending on the header template.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: b4866d192e6f4fdfba15b65fa2c209b35b7eb8c0
This commit also add the possibility to indicate a "top gap" = a part
on the top of the header which is not supposed to be shown once the page
is scrolled (this is a leftover of the "preheader" task which was
cancelled for something better, but that JS code still made sense as a
possibility).
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: 38ba41779f3b83219de41542e2132f0b9a194cce
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Since the images are now lazy loaded by default, the website menu was
not loaded correctly anymore when a mega menu was enabled and that there
was an image inside. Indeed, the menu loading waits for all images to
be loaded to compute the menu that should be in a dropdown when there
are too many. As the ones in the mega menus are hidden when the menu
is closed, the new lazy loading feature does not load them... which
makes the menu loading wait for something that is not being done.
This commit solves the problem by not waiting for images inside mega
menus. This could actually be done as a stable fix in stable versions
as there is no point waiting for those particular images in any case.
This will be only merged in master as it is not strictly a bug though,
at least for now.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: 2d9667c2286354bf22c1cfea06c06a6b9250ba24
For some strange reason, BS is handling small and large input groups
pretty well but not normal ones. Indeed when customizing the paddings
of buttons and inputs individually, the normal-size input groups are
broken. Also, customizing the border width of buttons always breaks
input groups for all sizes. This is now fixed.
Note: the first problem was actually already solved by increasing the
input height to the button height. It makes actually more sense to
shrink the button size to the input height as this commit does (as this
is the input which is the main element in an input group).
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: 7786d27bb42f1846442e37b7b2cba4a7c25131fb
The code in charge of adding inside a dropdown the menu items that would
be forced on a second line was not doing it properly when there were
some display: none items and especially not when there were neighbours
using the m*-*-auto classes.
Part of https://github.com/odoo/odoo/pull/56427
task-2264627
X-original-commit: 87a90f6816c0ce3db7d9d2edbe1b5149fd7bacff
Right now on few business objects (like leads, invoices, tasks, helpdesk
tickets etc) creation message contains
* subtype description;
* generic creation message;
This looks like multiple creation message on chatter after creation of the
record as you generally have "Task Created - Task created" (subtype description
then generic message).
This happens when we provide custom subtype on creation by by overriding
`_creation_subtype` method.
This commit fixes the issue by only using provided creation subtype and
removing default body. If creation subtype is not provided default creation
message is posted as before.
In this commit we also fix subtype for Lead/Opportunity creation and make
it generic ('Lead/Opportunity created') to avoid inconsistent behavior.
Finally some cleaning is made in method naming. Semi followup of 92e9e84b63
LINKS
Task ID-2288458
PR odoo/odoo#56631
PR odoo/enterprise#12707closesodoo/odoo#56688
X-original-commit: 2ebbeb4b5443c6405dd9a3b202a1eee9c5c67ebb
Related: odoo/enterprise#12728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
PURPOSE
Since v13 some commits added code in mail thread file. This file is already
quite long and keeping it organized allow to understand its content.
SPECIFICATIONS
Some methods defined on mail.thread may actually be called on models
not inheriting from mail.thread . Instead of having model methods on mail
thread receiving a records parameter it seems better to have those available
directly on BaseModel.
Move static_message_track on BaseModel in models.py. This method is now called
_mail_track, to be coherent with othe rmail-related naming. It is used in
accounting to track values in line model that does not inherit from mail.
thread. Update accounting accordingly (followup of d862965).
Move _message_get_default_recipients_on_records in models.py. Renaming it
_message_get_default_recipients() allow to be compatible with current behavior
and current override available in some addons (like CRM, event, ...).
Move _notify_get_reply_to_on_records in models.py. Renaming it
_notify_get_reply_to() allows to be shorter and coherent.
Move _alias_check_contact_on_record in models.py. Renaming it
_alias_check_contact_() allows to be shorter and coherent. Its override in
hr is also moved on BaseModel.
LINKS
Task ID-2327096 (code cleaning)
PR #56631
X-original-commit: f5df1ed912455e5ed52a65df3149f30a9d424de0
PURPOSE
Since v13 some commits added code in mail thread file. This file is already
quite long and keeping it organized allow to understand its content.
SPECIFICATIONS
Clearly separate CRUD / CRUD HELPERS / TRACKING / ... . Notably tracking
code was split accross two code sections.
Make some internal tools methods private. They do not require to be public
* with_lang: does not makes sense to be available outside of odoo. It is
renamed to _fallback_lang as it does not allow to set a specific lang in
the environment like with_user. It is used to fallback on user's lang
in context;
* get_mail_message_access: purely internal method used for access rights;
LINKS
Task ID-2327096 (code cleaning)
PR #56631
X-original-commit: 4a5fc70cfc3c86da33e2480fbd59c8f6d575c6e9
Before this commit, on page reload, sometimes web client crashed with
`Cannot read 'messagingMenu' of undefined`.
This happens due to messaging components making use of `messaging` in
`env` as if it was always set. In some rare cases, this is false,
hence the crash. This happens on root components of messaging such as
the messaging menu.
Creation of `env.messaging` has to be async, in other to ensure all
JS module that patches messaging are applied. The mounting of
messaging root components depends on other parts of the web client
like the SystrayMenu. So the proper fix is to guard `env.messaging`
on these root components.
Task-2238245
closesodoo/odoo#56684
X-original-commit: d1483ff3c83bb3146e80e5d65a27915c5b2a2bf9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- flush must be done before executing queries
- when the current partner is given, it shouldn't be checked twice
- when a channel includes the given partners but also has more partners, it
shouldn't be returned
- query can be limited to 1 result, minor performance gain in the rare case
where more than one canonical channel exists
task-2324119
closesodoo/odoo#56680
X-original-commit: b716dd9e62991997e03556f2d3e2483921fedef9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Upgrade scripts are now doing custom check on view/field/model unlink. This check
can be removed from odoo.
closesodoo/odoo#56657
Related: odoo/upgrade#1711
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
- Create a Contact named "Alpha"
- Create another Contact named "Mister X" with "misterx@alpha.com" as email
- Go to CRM and create an Opportunity for Mister X
- Go to Contacts and open Alpha
The Opportunities smart button shows 0, but when clicking on it,
Mister X's Opportunity is displayed.
The Opportunity smart button displays a "crm.lead" view with a filter on partner_id.
The filter applies an "ilike" with the Contact's name on several fields of "crm.lead",
including "email_from".
As Mister X's email address contains Alpha's name, its opportunity is wrongly retrieved.
opw-2320299
closesodoo/odoo#56667
X-original-commit: 547cc14d7fc4f39a00bf7a05b781c1edfa050cf6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Renames the "Table (MTO)" into "Table" and adds it a reordering rules
with 0 as min and max qty.
X-original-commit: b96b72c24aa80b9cdcfc2ebaf54438f3af6b1d9e
Creates a new PO to have more data to display in the product's forecast
report. The purpose is to make the demo of this report easier.
Also, replaces some tabs by 4-space.
task-2058495
X-original-commit: 3c3bd85b14e937b56938c1bc41acb3f1082b617b
Before this commit, creation of demo data purchase order wasn't into the
`noupdate` tag. So, if one of these records is manually deleted, then
purchase is updated, the record will be created again.
X-original-commit: d514f8dbbbacef58ce7ec1981e5ed321f6cf3bb4
Creates some SO to have more data to display in the product's forecast
report. The purpose is to make the demo of this report easier.
Also, increases the inventoried quantity of the `product_product_10` to
compensate the SO as this product is also used by other app demo data.
task-2058495
[IMP] stock: increase product_product_10 inv. qty.
X-original-commit: cecdc27fdf095374e1e640c5bf04c42a014af663
The purpose of this commit is to increase the acoustic bloc screens on
hand quantity, and in fact, it should be already the case.
But because of a duplicate demo data record's id, the inventory line
about the acoustic bloc screens was erased by an another inventory line.
task-2058495
X-original-commit: 9d6b7af61d35b03d2ab1a55268829d8760570f67
- Adds a MO for Table Top (2 units) to have a link between a consuming
and a replenishing MO in the new product forecast report.
- Generates finished moves for the demo data MO, so they can be retrived
by the forecast report.
- Changes date planned for the Table MO, so it will be planned after the
Table Top MO.
- Calls the `action_confirm` on the MOs in batch.
task-2058495
X-original-commit: d6b0c3dcfb2f9f926cef1d22c96e4f09afe0d6c8
Change the demo data to create pickings/picking batchs about deliveries
instead of internal transfers.
Made this change because multi-location is disabled by default so it
doesn't make sense to work with internal transfer with this config.
Also, renames these data records reference to avoid migration issue as
the pickings/picking batches picking type was changed.
Adds a second picking in the batch picking BATCH/00001 because it
doesn't make sense to have a batch picking for only one picking.
X-original-commit: ff2d4d77019a137008a7af5b0742c9ababeb5df9
The demo data creates a delivery with qty done but who can't be mark as
done because this picking has a move which has a move line (with qty.
done), but this move line isn't linked to the picking.
To fix that, this commit removes the manually created move line, calls
`action_assign` on the picking (this will create the move line and
correctly link them) then sets the `qty_done` on the move line.
Also, applies the same fix to done pickings who have the same issue (but
as they are done, it is less visible).
X-original-commit: 6732619941b9639897c00a3776429f50b38d1f9d
As long as the payment is not validated, the cashier can add products
to the order, even if the payment has been completed. The amount
authorized can be adjusted if the payment interface implements the
canBeAdjusted method.
closesodoo/odoo#56656
Taskid: 2117032
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Currently, admin and system users have the ability to manually create new
visitors from UI, which was introduced since ACL revamp[1] on visitors.
However, even admin should not be able to create visitors manually. Indeed
having a create button makes no sense as everything is managed through
frontend. Those menus are mainly present for reporting and displaying
information.
This commit fixes the behaviour by preventing manual creation of visitors
for all users including admin.
[1] - 5e605f5
Task ID-2288363
closesodoo/odoo#56651
X-original-commit: 1db514f8d2a9f1ba6861c89ced9a2a9f5dcf48be
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
when creating the first bank statement on a journal. It will trigger
manual field recomputations:
https://github.com/odoo/odoo/blob/d19477f982e046ba563ce18706f0eab2b250738d/addons/account/models/account_bank_statement.py#L288-L297
previous_statement_id will correctly be False
The manual recomputation in create will recalculate all bank
statements that have a False previous_statement_id.
These bank statements are usually the first ones in a journal. When they get
recomputed it triggers recomputations for every bank statement that
follows it.
This commit try to limit this behavior by recomputing statements only in
the same journal
opw-2311173
closesodoo/odoo#56648
X-original-commit: e932df3b356752eb9c42164821acb6e2db7fe317
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a user U linked to an employee E
- U has no right in Project and he is timesheet user
- Let's consier a leave type LT generating timesheets
- LT is linked to Internal Project IP and Internal Task for timesheet ITT
- IP has privacy "on invitation only"
- U makes leave request LR for leave of type LT
- His manager approves LR
- U goes to My timesheets list view and select the timesheet generated by the approval of LR
- U prints Timesheet Entries
Bug:
An access rights error was raised.
opw:2321040
closesodoo/odoo#56615
X-original-commit: 31a9faa7c83029386da5e1bac01dda0d124f8970
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Doesn't seem used since it's been broken forever on python 3:
base64.b64encode returns binary data, on which json.dumps chokes.
Still, removing the endpoint on old stables seems a bit brutal so just
fix it.
closesodoo/odoo#56650
X-original-commit: 7fc9bc28986d69184df5a4fdeefbe09e4b39b8f0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If there is no `date_end`, sorting will crash.
opw-2326262
closesodoo/odoo#56603
X-original-commit: e981c17dd93c756a5cf0384ab2dcc25ef58cb1b1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, `stock.warehouse.orderpoint` `_compute_qty` didn't
depend on `purchase.order.line` (POL). This means when a relevant POL
was edited/cancelled, then the `qty_forecast` wouldn't correctly update.
To reproduce:
- Create a product w/ a vendor and buy route active,
- Go to replenishment report, create a reordering rule, and hit
order for product (RFQ should be created)
- Cancel the RFQ and go back to replenishment report
The product should reappear in the list view, but does not because it's
`qty_forecast` has not updated and therefore has not updated
corresponding `qty_to_order` value.
Note string rename of `purchase_line_warn` 'Purchase Order Line' =>
'Purchase Order Line Warning' is due to repeat label use issue. It is
better to rename the poorly labeled `purchase_line_warn` than to give a
hacky label for new One2many field.
Task: 2285912
Manual forward port of: odoo/odoo#56580 due to migration test error
closesodoo/odoo#56625Closes: odoo/odoo#56625
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, Creating a new Credit Note will log `Refund Created` into the chatter, and creating a new Vendor Refund will log `Credit Note Created` chatter due to wrong types given in `_get_creation_message` method.
With this commit, We use the correct type in this method.
closesodoo/odoo#56618
X-original-commit: 4d2d9f030d6a5a56657d30586ba6fc0bbd688fca
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The Form class already handles cases for attrs that contain boolean
values, e.g.:
`attrs="{'readonly': True}"`
But it doesnt for integers, e.g.:
`attrs="{'readonly': 1}"`
This commit changes the expected non-domain value from boolean to
integer, because both are valid cases and the former is a subset of the
latter.
[1] https://github.com/odoo/odoo/blob/b3d4938ba6b1/addons/repair/views/repair_views.xml#L54closesodoo/odoo#56612
X-original-commit: 782534a429f10e7b114c838687d38aa4080a920c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Luis González [Vauxoo] <luisg123v@users.noreply.github.com>
Currently the method `read` uses by default the parameter `load='classic_read')`
- `self.read(fields, load='classic_read')`
So, it computes `name_get` for all m2o fields for all records in `self`.
If you want to avoid computing the `name_get` to save time and process
You can use an empty string in load parameter:
- e.g. `self.read(..., load='')`
The method `self.search_read` call to `search` and `read` methods
but `search_read` method is not possible to assign `load=''` argument
(or other arguments of the method `read`)
- e.g. `self.search_read(..., load='')`
So, you need to use 2 lines of code:
records = self.search(...)
records.read(..., load='')
This commit changes `search_read` method to receive all keyword arguments of the method `read`
So, you can use `self.search_read(..., load='')` and the `read` parameter will be propagated
closesodoo/odoo#46391
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Cocographique