Before this commit, it was not possible to scroll a popup with a
dragged snippet.
Part of https://github.com/odoo/odoo/pull/61998
task-2312878
X-original-commit: edf28efe19bedfe5eb62baf6fa5832a50d18e775
Before this commit, open invisible elements were not closed before
being deleted. This created issues like the 'modal-open' class wich
was not removed from the body when removing a modal.
Part of https://github.com/odoo/odoo/pull/61998
task-2312878
X-original-commit: a67f7df31a9e5a5550d54d52ae506299f4a62581
When a modal is open, allow the drop of a snippet only in this
modal.
Part of https://github.com/odoo/odoo/pull/61998
task-2312878
X-original-commit: 2f38816f279717bca38166a22c4f692a7f1d10c0
Before this commit, when scrolling a snippet popup, the overlay was
not updating its position.
So now, we use addEventListener instead of jQuery for the scroll event
on the scrolling element because we need the 'capture' parameter.
Setting this capture parameter to true allows us to take advantage of
event bubbling for events that otherwise don’t support it.
Part of https://github.com/odoo/odoo/pull/61998
task-2312878
X-original-commit: e734df614a07d51cfd2c9eb6e3876189e1d22a69
Co-authored-by: Samuel Degueldre <sad@odoo.com>
- The modal content of the popup snippet had a maximum height of 100%
because of a global rule on modals. But, here, the scrollable element
is not the modal so we dont want this rule.
- For the popup to be scrolled correctly we also had to remove the
rule that adds a fixed 100% height on modal-dialog and we added a
min-height of 100% to correctly display the popup in the middle
position.
Part of https://github.com/odoo/odoo/pull/61998
task-2312878
X-original-commit: 9cd8c15ed22e3033c654fcfa28f76b79083dcf98
This is not really a big issue but let us have correctly defined
rules.
Spotted during Task ID-2300230
closesodoo/odoo#65160
X-original-commit: ac03898e72cab28efe103aa3d5e9fca0eee78240
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Behavior prior to this commit:
When a PO is generated (via reordering rule, mto rule, or manual replenish),
the description on the PO line includes the internal notes.
Behavior after this commit:
The description on the PO line does not include the internal notes.
Note:
Per c324526ad0, the description on the picking also does not include
the internal notes (anymore), and the test has been updated to reflect
that.
opw-24222438
closesodoo/odoo#64883
X-original-commit: 5db67fb2931517ae94fe0396ef80e9ad997e59cd
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Issue
- Install "Accounting" module
- Ensure there is more then 20 journals ( or
must do a zoom-in on the browser)
- Go to Accounting -> Reporting -> Profit and Loss
- Click on "Journals" filter
Not all journals are displayed.
Cause
No scroll or max-height set on dropdown.
Solution
Set a max-height and an overflow:auto on `.dropdown-menu`
and `o_dropdown_menu` css classes.
opw-2430101
closesodoo/odoo#65167
X-original-commit: cf351ae49875ec7d28a18747b65ed2a61f55262b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The 'custom' key was not working anymore as a key to exclude the
ability to choose a custom color from a color palette widget. It was
thus appearing for choosing the transparent color for over-the-content
headers... which is not possible to save right now.
Part of https://github.com/odoo/odoo/pull/65139closesodoo/odoo#65154
X-original-commit: 8f9eb57df5c6a253ee0702c0e1fb2016cab7eb1e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Users can choose one of their color combination to apply on the header.
If they then choose to make the header transparent over the content for
a specific page, the color of buttons & other components in the header
should be reset to the default website color combination's colors as the
header component are now appearing over the default content.
Part of https://github.com/odoo/odoo/pull/65139
X-original-commit: 2172295cefa1d8780332709bf0c97cfa23def3a5
Improve various event views, notably:
- Display ticket description on frontend even if there is only a single ticket
- Do not display search count on frontend agenda page when there is nothing
searched
- When performing a search, only check the text content of the track HTML
elements and not the entire HTML content, otherwise it would lead to incorrect search
results
In addition, we now also display an human readable error message when the user
tries to delete tickets that are linked to registrations.
This will help identifying the problematic tickets and remove the associated
registrations if necessary.
Task-2427778
closesodoo/odoo#64187
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When checking the replenishments, it sometimes creates a new reordering
rule for a product while another already exists.
To reproduce the error:
(Need purchase,sale_management)
1. Create a product P
- Must be storable
- In Purchase tab, add a vendor
2. Create a reordering rule for P
- Trigger: Manual
- Min: 0
- Max: 0
3. Create+Confirm a SO with P
4. Go to Inventory > Operations > Replenishment
5. On P-product's line, click on "Order Once"
6. Confirm the generated RfQ
7. Repeat 3-4
Error: There are now two lines for P-product. A second reordering rule
has been automatically created but the first one does already the job.
OPW-2431780
closesodoo/odoo#65142
X-original-commit: a9d5bd2ebb28a9bf0aa8d4adb0992582e85c54fc
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Otherwise, this can raise the below issue during an upgrade (`-u`):
```
File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 369, in init_models
model._auto_init()
File "/home/odoo/src/odoo/13.0/odoo/models.py", line 2529, in _auto_init
new = field.update_db(self, columns)
File "/home/odoo/src/odoo/13.0/odoo/fields.py", line 2456, in update_db
return super(Many2one, self).update_db(model, columns)
File "/home/odoo/src/odoo/13.0/odoo/fields.py", line 857, in update_db
self.update_db_notnull(model, column)
File "/home/odoo/src/odoo/13.0/odoo/fields.py", line 897, in update_db_notnull
model._init_column(self.name)
File "/home/odoo/src/odoo/13.0/odoo/models.py", line 2455, in _init_column
value = field.default(self)
File "/home/odoo/src/odoo/13.0/addons/utm/models/utm.py", line 28, in <lambda>
default=lambda self: self.env['utm.stage'].search([], limit=1),
File "/home/odoo/src/odoo/13.0/odoo/models.py", line 1648, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/13.0/odoo/models.py", line 4497, in _search
self._cr.execute(query_str, where_clause_params)
File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 173, in wrapper
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 250, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UndefinedColumn: column utm_stage.sequence does not exist
LINE 1: SELECT "utm_stage".id FROM "utm_stage" ORDER BY "utm_stage"
```
upg-5396
closesodoo/odoo#65135
X-original-commit: 9294c1dc4f24c23c1f81bec50d73cb594349b54b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
To reproduce, product A in AVCO:
- Buy 2 product A at 1.00 $
- Buy 1 product A at 1.01 $
- Sell 3 product A.
- The stock valuation won't be correct: still remain 0.01 in
stock without quantity and the svl related to the sell
have a value of 3.00 (instead of 3.01)
To fix:
In case of AVCO, add the rounding error value to the out
stock move layer.
closesodoo/odoo#65117
X-original-commit: f6b019fcfdd35a693e8af43ae38d10e31e96284a
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When synced with Google, if a user adds an event to Odoo Calendar, both
Google and Odoo will send an invitation to attendees.
To reproduce the error:
(Need mailcatcher)
1. Sync Odoo Calendar with Google Calendar
2. Create an event in Odoo Calendar
- Add at least one attendee who has an email address
3. Save
Error: Odoo's server sends an email. When synced, it should not, it
should let Google in charge of emails sending.
(Similar to #62383)
OPW-2440485
closesodoo/odoo#65125
X-original-commit: c0a2729d4b7ba6fefe4dbde9247b2e6e868f5771
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Right now, the default invoice policy policy for the products is set to
'delivery'. However, in the case of event ticket products, usually you
don't really handle the "delivery" of the ticket. It's most likely to be
sent by email automatically.
With this commit, the invocing policy for the default ticket product is
set to 'order' to ease inovicing the SO. Apart from default product, the
onchage method for 'event_ok' is adapted for setting the correct invoice
policy and product type.
Task Id : 2243915
closesodoo/odoo#63725
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Install purchase and stock;
- Activate Units of Measure (uom);
- Create a new storable product;
- Choose a different uom for: 'Unit of Measure' (e.g., Dozens) and
'Purchase Unit of Measure' (e.g., Units);
- Update the Cost (e.g. $ 300.00 per Dozens)
- Create a PO;
- Add the product.
Before this commit, the price on the PO will be 300 and the unit of
measure will be 'Units'.
Now, the price will be adapted to the 'Purchase Unit of Measure', in
this example it will be $25.0 per Unit.
opw-2439506
closesodoo/odoo#65119
X-original-commit: 27d251a17f3ccc597e2cd277b6d40a31dc9889b2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
If a product is a kit and has a storable component, if this component is
already ordered (with sufficient quantity), when running the scheduler,
the ordered quantity of this component will still be increased.
To reproduce the error:
1. Create two products P_kit and P_compo
- Both are storable products
- P_compo must have at least one vendor
2. Create a BoM for P_kit:
- Must be a kit
- Add P_compo to components
3. Set a reordering rule for P_kit
4. Inventory > Operations > Run Scheduler
5. Go to Purchase and find the generated RfQ
- The ordered quantity is correct
6. Repeat 4-5
Error: This time, the ordered quantity is incorrect. While you don't
have any P_kit on hand, each time the scheduler is run, the ordered
quantity will increase.
A similar issue has already been fixed: #63891. The original commit
targets the version 13, but the fix has also been applied to v14 (#64277).
However, here the case is slightly different: the user run the scheduler
twice while the first RfQ is not yet confirmed and received. In such a
case, the scheduler must also check the "quantity in progress". In version
14, it seems nothing computes this quantity for the kits.
OPW-2421841
closesodoo/odoo#65100
X-original-commit: f53ab55000c32fd67c567f01a9533298936daaac
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
For now, when you are selling products in the point of sales, the stock
is affected once the order is validated or the session closed. But in
some case, you don't have the product in your store, and you have to
plan a delivery for the order.
To be able to plan a delivery, you can now choose the warehouse in POS
Config and the routes of your warehouse will be applied. You can also
set a specific rule on your POS Config if you've enabled the
multi-step-routes in the inventory module
closesodoo/odoo#58506
Task-id: 2082104
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Adjustment of a previous commit b1dff85a85
It is possible for the argument to be something else than `undefined` or an array. We're adding a check to prevent an error to occur in that case.
closesodoo/odoo#65098
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The regex was updated in JS with [1] but its python counterpart was
forgotten during forward-port.
[1]: https://github.com/odoo/odoo/pull/46898closesodoo/odoo#65087
X-original-commit: 8d0b82683b95615267ff3acf84ebdd20456c595a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Create a promotion program PP
- Set 50 in minimal amount
- Set promo_applicability = on_next_order
- Set reward_type = discount
- Set discount_type = discount
- Create a new sale order SO with a product with price 100€
- Cancel the SO
Bug:
A coupon C had been created
PS: When reset to draft and confirm SO, C became valid
Closes#64361
opw:2431740
closesodoo/odoo#65067
X-original-commit: c2ce00173c612d38dd8dc6b1f15edf2261f2acc6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider two companies C1, C2 and a website W1 in C1
- Set C2 on the payment term Immediate payment
- Go to the shop
- Add a product in the cart
Bug:
A traceback was raised because Immediate was not in company C1
opw:2431705
closesodoo/odoo#65066
X-original-commit: 48ec6f2e4f91e4d1317b246b7017f78746161450
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
commit 31e1322b40 is allowing the
customer to increase is decimal accuracy for currency without
consequences but triggering issue upon lowering it if entries
already exist.
+ Remove the redirection to the support.
Let's ensure that the behavior is consistent and the users are
warned on first modification. To do so, adding an alert msg
in addition of the blocking message in case of lowering the decimal
accuracy after already creating accounting entries.
opw-2428857
closesodoo/odoo#64757
X-original-commit: 66533ebd88ed89c3baae6fdb1d0a28a458fa0cb9
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Install "Manufacturing" module
- Go to settings and activate "Master Production Schedule"
- Install Dutch language
- Switch user language to Dutch
- Go to Manufacturing -> Planning -> Planning by Production
- Hover work order
Dates are not displayed with user locale.
Cause
Date are formated to "YYYY-MM-DD HH:mm:ss",
regardless the locale.
Solution
Format date instead with locale format letters (L, LL, LTS, ...)
Doc : https://momentjs.com/docs/#/parsing/string-format/
Go to "Locale aware formats" section
opw-2430570
closesodoo/odoo#65092
X-original-commit: 08978c6d2d14a94e6ee2fea0dedc805a56378de0
Related: odoo/enterprise#15970
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
with this commit we fixes various tour steps, remove steps from crm and sale
tour and improve step selector in project tour.
task-2444272
closesodoo/odoo#65073
X-original-commit: f6c05693f857acfb0f74bb76c4bd72f83d9fb335
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit saving a custom snippet inside an email template
produced a "cross origin" error related to the combination of the save &
reload mechanism with the fact that the email template editor is inside
an iframe.
After this commit saving a custom snippet inside an email template is
not available anymore.
Given that fixing the reload problem would be only temporary -while
quite complex-, it has been decided to disable the feature until the
editor allows for cleaning snippets without saving them.
Decided during task-2374802
closesodoo/odoo#65052
X-original-commit: 86333160f92c16bc61f36b413caed325f8ac59a0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Start odoo in threading mode with bus installed. Login in the browser
using any internal user. Make sure the browser call the
/longpolling/poll uri. While the browser is waiting for a response, stop
the server. The server takes up to 50 seconds to stop.
When started in threading mode, a request to /longpolling/poll is served
by a casual http thread. It searches for messages enqueued in the bus
and returns them. If there are no message for the user in the queue yet,
it creates a `threading.Event`, attach it to the user in a shared
dictionnary and `wait()` on it with a timeout of 50 seconds (hardcoded
value). When the bus thread (the one responsible to listen on the
database) receives new messages, it `set()` the events which resume any
http thread that was waiting.
Because when we stop the server, there is no way to server new requests,
there are no way new messages arrive in the bus. All the threads that
were waiting for a new message will just wait until the event timeouts
which slow down the shutdown of the server.
Now we actively `set()` all events in order to resume all those workers
when we stop the server.
The `ImDispatch.poll` signature has been changed too so it is possible
to change (via code) the hardcoded default. The function was using the
object referenced by `TIMEOUT` at the time the function was defined,
using `timeout None` then `if None: timeout=TIMEOUT` ensures we lookup
the variable.
closesodoo/odoo#64530
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Before this commit, the countdown snippet was layouted vertically on
mobile devices.
After this commit, the countdown snippet is layouted vertically,
just like on desktop.
task-2349095
closesodoo/odoo#59756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Siddarth Gajjar <sga@odoo.com>
Before this commit the user had to type in the exact same formatting to find contacts.
After this commit the user will be able to get better search results and does not have to type the same formatting.
To avoid code duplication, the existing _search_mobile_phone method has been moved to the mail_thread_phone class, so that it could be used by both the crm and res_partner models.
Task-2435233
closesodoo/odoo#64490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The uom must be displayed to the customer in any case.
Otherwise a customer couldn't know the modalities of a contract
(ex: a contract of one year or one day)
Fine tuning of 342dd5f
opw:2411108
closesodoo/odoo#65048
X-original-commit: 29fb2f93d218109edd1db1e94555bf4b58d25158
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The .po format is wildly used in Odoo and is the format used for storage and
interaction with Transifex
closesodoo/odoo#65039
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Modifying product attributes involves discarding product variants via
the method _unlink_or_archive(), which tries to delete variants, and
archive the ones for which the deletion fails. This process is very
slow when most product variants must be archived. Instead, we filter
out the variants that must be archived anyway (like the ones used in
sales or stock), in order to avoid the variants that cannot be deleted.
On a product with ~200 variants, the time goes from more than 15 minutes
(the request times out) to around 5 seconds!
opw-2440417
closesodoo/odoo#65027
X-original-commit: 63b2f85079404eafac918a74c95e27051539c133
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Also did below improvements/fixes,
- Added missing .pot file for internationalization and re-exported
Swedish translation file and adapted the translation.
- Fixed partner view by inherting it from account instead of base.
- Constrain method should not 'return' ValidationError, it should
'raise', it is now fixed.
closes odoo/odoo#53298
Task: 2279356
Closes: #53298
Related: odoo/upgrade#1371
Signed-off-by: William André (wan) <wan@odoo.com>
Issue
- Install calendar
- Go to calendar and set 'week' view
- Go to first week of the year
- Add a 'Full Day' event
- Add an event of 'few hours'
- Click on filters -> Date -> Q1
Only 'Full Day' events remains displayed.
Cause
'start_date' is used to in the 'Date' filter
and this field is set only on 'Full Day' events.
Solution
Use 'start' field instead since always set.
opw-2439460
closesodoo/odoo#65022
X-original-commit: 5f13ac8cf52c2042fe0b4697cbf41aa7f8714427
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The affixed header was not reappearing if page content was removed and
the page thus indirectly scrolled.
task-2446020
closesodoo/odoo#64999
X-original-commit: 4da6df09a4df195ad7c0caa7de7fbc7389339958
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The uom must be displayed to the customer in any case.
Otherwise portal user couldn't sign their online quote if
they couldn't read the uom (ex: a contract of one year or one day)
opw:2411108
closesodoo/odoo#64993
X-original-commit: 342dd5ffb8281cb5c37fea4fb96db2b570c30122
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Benjamin Vray