Issue
- Install eCommerce with any theme
- Website > Enable optional product
- Create a SO with an optional product
- Save > Customer Preview
- Mobile view with inspector
- Click on the shopping cart icon in
the optional product line
Quantity selector is not correctly
displayed
Cause
First, the input width is 50%, which
means very small on mobile and there
are paddings on the input and the buttons
Solution
Remove the 50% width and paddings on mobile
It allows to see 3 chars on very small
mobile screen.
OPW-2220893
closesodoo/odoo#48423
X-original-commit: 38e90e09239eb75bd25001c7870758b380159ad0
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
When the currency_id is unset from the invoice and account moves are set,
by means of updating taxes or the line itself,
since there are no checks on the actual presence of a currency,
currency methods will invoked causing crashes.
Imposing the condition directly on top of the onchange solves the issue.
Since the currency_id is a required field for the invoice the
recomputation will be triggered again with the correct values.
opw-2192628
closesodoo/odoo#48458
X-original-commit: f795b1bc7b42bdcbd4bd9895616461d2702f1e41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- install project, studio
- activate ratings for projects and create a kanban view with the rating model
(trough studio)
Previous behavior:
some images in the kanban view are not displayed
Current behavior:
all images are displayed properly
opw-2205549
closesodoo/odoo#48462
X-original-commit: 4b5691dee5a397551ca92a9ac78571ce7f82f276
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Website has a behavior that will ask you which menu you want to edit if you
click on 'Edit Menu' in the topbar and there is more than one menu in the DOM.
This is typically the case for the event pages where the event has its own menu
on top of the website one.
This event menu was not triggering that behavior since 5b563549fa where is
was accidentally broken.
closesodoo/odoo#48459
X-original-commit: 5c3c91e4a8da7b7b9f5e05f9c0ec5a6dea782d87
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Purpose
This merge fixes several issues on the slide list in front-end.
Specifications
* fixes reordering of slides in case there are some uncategorized
slides in the course;
* fix slide upload issues when adding it in an uncategorized category;
* fix resequencing based on a category;
* fix empty flag display whenever a slide gets drag&dropped/archived;
More info in sub-commits.
Links
TaskID 2090927
closesodoo/odoo#48452
Forward-port-of: odoo/odoo#48411
Forward-port-of: odoo/odoo#39086
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, empty sections were not flagged correctly whenever a slide
got archived or dragged to another section. This is due to the empty flag is
not updated accordingly.
Taskid: 2090927
X-original-commit: 43f05c0b92cf24812187490fb326fb6cfd9ca021
This commit fixes the reordering of slides on upload or drag and drop
in frontend. This issue was due to the fact that in a previous commit
(c4eba6f) uncategorized slides were moved to the bottom of the list,
which broke the reordering after drag and drop.
Indeed we use the dom order itself to reorder the slides with a simple rpc
call to dataset/resequence. Instead we revert part of the previous fix
to display uncategorized slides at the top. It allows to be coherent with
resequence and with backend behavior that displays uncategorized at the
top of the list.
Another issue was that, on slide upload, in the controller, we used
the category_id on the slide (which seems to not always be correct at
this stage) instead of the one given by the javascript. This caused the slide
to not be uploaded in the right section.
This commit also adds some margin to the categories in frontend for training
courses. Otherwise uncategorized slides are too close to the first category.
Task ID 2090927
X-original-commit: 7bd042d6e20c44558b90641409a6e3f8fa8000ed
When new slides are added through frontend a resequencing of slides and
categories sequence is done by calling _resequence_slides on the channel.
However this method is not working as expected, and resequencing should
take a category in order to better know where to start its resequencing.
Otherwise it simply reorder slides in the same order as before, or in an
unpredicted or prodicted but fasly order if new slide category has just been
created.
Task ID 2090927
X-original-commit: f038946ae2e3f174bee086281a541c6bc770e354
PURPOSE
Before this commit when updating an event with website_menu, website_track or
website_track_proposal activated it created an extra sub menu even if already
created. This commit fix this issue.
SPECIFICATIONS
Check if the menu doesn't exist before creating it.
LINKS
Task ID : 2210441
PR : #47058closesodoo/odoo#48451
X-original-commit: d6e334d48aace3fce196bb0652915cd5232ffbe7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reduce number of queries on base method like dispatch, or base controller like /web/content
Part of task-2211013
Following
https://github.com/odoo/odoo/pull/46925https://github.com/odoo/odoo/pull/47257
Most of these small queries are done in part of code called a lot of times.
Next step is to be more 'controller' specific, and reduce query / imp perf
for specific page /my /blog /forum /shop ...
Courtesy of Rco and AL for help and validation
closesodoo/odoo#48165
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Jérémy Kersten <jke@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
# Purpose
**Add tags and category of tags in event and make various improvements in event app**
# Specs
- Add tags that users will be able to filter events with.
- Light design improvements in /event page
- Improve event registration in front-end
# Links
Task ID 2188807
closesodoo/odoo#44690
Related: odoo/upgrade#998
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In case of short controller that don't use qweb template, we don't need
anyhting else that this url code that don't change frequently.
It make only sense for model like lang, website, ... that will not change
frequently. And are called on each call by the dispatcher.
In case of a website page, we will btw browse lang later, but in case of
small controller like /favicon.ico, or page without qweb, ... we can just
use the same from last query.
If model is already an ir.attachment we don't need to do a new search_read.
We can use it record directly.
After this commit, we don't do extra request if we already have the info,
else we don't change the behavior.
task-2211013
The dispatching layer of Odoo (common to any call) can avoid a query on website
if those 3 values are cached.
Note that for complex business flows, there won't be any gain since website
infos will have to be fetched at some point.
About user_id:
In most cases, for a website page you will need to browse the website btw so
we don't remove this request previously. But in case of a simple image, the
controller /web/content need the public user just to set the request.uid in
auth_public but no other info from website.
With this commit, we don't do the 'select * from website where id in()'
request on each controller declared in auth='public' but use the user_id
from the cache. (Invalidated by the write on website_id)
task-2211013
Co-authored-by: Jérémy Kersten <jke@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Most of the time, the record exists, but we still ensure it does, every single
time, making an SQL query.
Doing a try catch will result in the same behavior, but won't make that query
most of the time.
task-2211013
If we are rendering a page, the menus will most likely be rendered as well.
Note that even in a 403 case when the page is found but is not visible, the
menus will also be shown on the 403 page.
Fetching the menus before accessing the requested page will prefetch that page
as well in one go if that page is in the menus, without any costs for the pages
not in the menus.
There is a tradeoff for 'non-layout' pages, which only occurs in advanced
technical cases:
1. Create a page with specific extension as name suffix (page.css) in which
case the page will be bootstraped accordingly, without call to layout.
2. Remove the call to layout in HTML editor or backend
3. Remove the call to submenus template in HTML editor or backend
For those cases, the menus will be prefetched for no reason.
Note that homepage '/' is rendered through a controller, same logic is applied
there.
task-2211013
Render page flow:
- Search website.page in _serve_page for requested URL
- Check if the page is visible with `is_visible`
- `is_visible` will get the `ir.ui.view` of the page
Note that this is not 'cachable' as being visible depends of now() for the
publishing date
- Render layout which is getting the website menus
Note that this can't be cached either as a menu visibility might also
depends of it's website.page visibility which depends of now()
- Checking menus `is_visible` fetch the menus pages and those pages views.
Before this commit, every level of menu hierarchy would add 2 queries.
This can be avoided by prefetching everything in once during the dispatch if we
know we will render the website menu.
In such a case, read `is_visible` on every website menus will fetch every
pages, views and menus in the lowest SQL queries possible, eg one query for
every table.
For a 3 level menus, requests goes from 20 to 12 to load a untracked page.
task-2211013
- Refactor for easier readability
- Add a test to ensure menu hierarchy scale correctly.
- Add tests for image controllers
- Add test for assets controllers
task-2211013
When creating a website, we:
1. Create the website
2. Bootstrap a homepage
3. Copy the generic menu hierarchy tree for that website
But since we just bootstraped a homepage for the website, the home menu was not
using that page but the generic one from the xml data instead.
That's an issue for tests recently introduced in master that needs the relation
to be correctly set for the query count to work as expected.
task-2211013
Before this commit the documentation had quite some samples with 'customer', '=', True. Since in V13 this field on the res.partner model no longer exists we've removed it.
closesodoo/odoo#48453
X-original-commit: 2215d803aa35cdd13ab7f989c807bc7f575aaa8e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
On event cards of the /event page, the "bubble" with the date would appear
blank in bootswatch theme.
This commit forces the text to be black and therefore visible.
LINKS:
TaskID:2162438
PR: #43856
Before this commit, no location was shown on the event page
if the event was online.
This commit changes that so that it clearly displays that the
event is online.
LINKS:
TaskID:2162438
PR: #43856
Purpose:
Fix a few minor issues with the design and make some light
UX improvments.
Specs:
- In customize menu, show templates should be set as False as templates
are more of a technical thing anyway.
- In location filter, fix the alignment for the "online" option.
- Fix card design in case "show templates" is True and the event is online
- Make the whole event card clickable
LINKS:
TaskID:2162438
PR: #43856
Purpose:
Improve the registration on front-end by allowing the manager
to customize it and display more informations to users about the tickets
and the status of the event.
Specs:
For event manager:
Allow users to decide wether or not they want to unfold/fold
ticket details on their event. The reason behind this is that
some events might have 5+ different tickets and having them unfolded
would bloat the UI quite horribly.
By default, ticket details should be unfolded with no possibility for the end users
to fold it back.
Always display a button for the manager to go configure the event in back-end
For users in general:
Show price range in case the ticket details are folded.
Clearly show the user that a particular ticket is sold out/expired
Cleary show the user that registrations are open/closed/sold out
LINKS:
TaskID:2162438
PR: #43856
Before this commit, _compute_sale_available would only take into account
the dates to set the field sale_available.
This commit makes it take into account the number of available seats
for the ticket as it is wrong to consider a sold out ticket as
being available for sale.
LINKS:
TaskID:2162438
PR: #43856
This commit changes the display name for the model event.type from
"Event Category" to "Event Template"
This change was needed before introducing the new model event.tag.category
which will be used to group tags (event.tag)
This commit introduces two new models: event.tag.category & event.tag
The tags will be grouped by category and will be used to filter events.
In the front-end, if the user activates the "filter by categories", each
event.tag.category will generate a new dropdown of related tags.
Clicking on one of these tags will add a new "tag badge" above the events
(same way as in eLearning).
LINKS:
TaskID:2162438
PR: #43856
Confirms and plans the manufacturing order created for table (MTO) in
demo data to have already a work order.
task-2199747
closesodoo/odoo#46464
Related: odoo/enterprise#8922
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Sets the currency of supplier info (purchase price) in demo data on USD.
The reason is the default company currency is EUR, so the supplier info
created use the company currency by default.
But once account is installed, the company currency is switched for USD.
As multi currency is inactive by default, the user can't see the product
purchase prices aren't in the same currency than all the other prices.
task-1970460
Adds quantities in starting inventory and adds a "Starting Inventory"
for the Chicago Warehouse. The purpose is to avoid to have negative
values in demo data.
Task #1970460
Rename warehouse of compagnies as following:
- YourCompany -> San Francisco
(WH) (WH)
- My Company (Chicago) -> Chicago 1
(MyCo) (CHIC1)
- Chicago Warehouse -> Chicago 2
(Chic) (CHIC2)
Also, can pass a default code through the context when create a new
company to set the `code` value when creating the default warehouse for
the newly created company.
Task #1970460
Before this commit, some tracked product quantities didn't have a SN/LN.
To avoid some issue at the use, it's better all demo data fulfill
requirements like that.
Task #1970460
Demo data product's quantities are no more put in sublocation as by
default, multilocation aren't active.
Also, adapts `test_location_usage` because as we moved quantities from
sublocations to the main stock location, the stock warehouse will have
reserved quantity due to a backorder created by demo data.
In this test, we try to change location as a scrap location, what we
can't do if this location has some reserved quantities.
Task #1970460
<h2>Description of the issue/feature this PR addresses</h2>
Update UX for blacklist management of "mass mailing" and "mass mailing sms" by:
- Making phone and email blacklisting text / UX more consistent
- Making it easier to remove a phone/email from blacklist
- Improve GDPR compliance by adding in a "Reason for unblacklisting" via a wizard for traceability
<h2>Current behavior before PR:</h2>
A blacklisted phone number or email address can only be removed from their respective blacklist by going to the corresponding blacklist view [in mass_mailing_(sms)] and manually archiving the entry. All users could see that an email was blacklisted via an fa-ban icon added next to their corresponding field in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via extension). Some UI inconsistencies between the Phone Blacklist and Email Blacklist implementation exist.
<h2>Desired behavior after PR is merged:</h2>
Add additional fa-ban icons next to blacklisted phone numbers and make all instances of these icons clickable to remove their corresponding field value from blacklist using a wizard. When submitting a value to be unblacklisted, a "Reason for unblacklisting" is possible to help with GDPR compliance. Additionally use same wizard as a "Unblacklist" button within form view in phone/email blacklists.
Task ID: 2117635
Upgrade PR: https://github.com/odoo/upgrade/pull/939closesodoo/odoo#45315
Related: odoo/upgrade#939
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315
In 13.0, as of 369c20a9 there is some style that will show an event with
bigger font-size and spacing in calendar day view.
In this commit, if an event is short (less than 30 pixels, so less than
45 minutes) we will decrease the spacing to have the same as in week
view and see the event title more easily.
opw-2216654
closes#48391closesodoo/odoo#48409
X-original-commit: a4d170ad9e73d1d63404532b161911df020b5c36
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
After d3ddcc613f l10n_it_edi started to
fail its tests because not adapted, porting the code from the same commit
fix the issue
opw-2214185
closesodoo/odoo#48397
X-original-commit: 33e80333b84d71ae0f61d4ab0e3aa7fdfcdf0f78
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When user apply half day leave in Leaves, the approver should be able to check
whether it's morning or afternoon on the approval page.
closesodoo/odoo#48429
X-original-commit: 3d3de2bf991bf4a10566599d3bb9011e4c09d21f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Minor UX tweaks for more consistent and correct wording, visualization,
and editing ability for mass_mailing and mass_mailing_sms. Specifically:
- Fix all "This email is blacklisted for mass mailing" => ".. mass
mailings" typos
- Make phone blacklist not editable (to align w/ email blacklist)
- Add "Archived" ribbon to phone and email blacklist
- Update menu items and actions
- "Phone Blacklist" => "Blacklisted Phone Numbers"
- "Blacklist" => "BLacklisted Email Addresses"
Supports task: 2117635
Simply create an SO with more than 1 Qty and deliver. An untaxed amount
is shown on the SO.
Check in Sales > Reporting > Sales > Pivot view, the Untaxed amount
Invoiced and Untaxed amount to invoice Measures. They show the right
amount.
Make a partial return from the original SO and validate.
Reduce the quantity on the sale order line.
The sales report is not updated with the right untaxed amount to
invoice. This occur because when the sale order line have an increased
qty_ordered a chain of event is triggered which included the
recomputation of the untaxed_amount_to_invoice which does not occur on
decrese.
Adding the product_uom_qty to recompute triggers fix the issue
opw-2213996
closesodoo/odoo#48282
X-original-commit: f8a5366ea650c1a2ac4ad3a42da7da4a34758d60
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This happened:
- The user clicks on a parallax snippet
- For each option, call onFocus then updateUI:
- The BG position is first, so update its UI
- The parallax option is last, onFocus changes the BG position target
... this is broken since the BG position option was updated before the
parallax one was able to change its target. So the BG position was
updated by checking the background type of the snippet instead of its
internal parallax <span/> element.
This was working in 13.0 as changing the target automatically re-updated
the related option UI, now this is left to the dev to update the UI
afterwards or not.
In this case the fix is simple: the onFocus of all options should be
called, before calling the updateUI of all options. This actually
allows to make the code cleaner.
closesodoo/odoo#48428
X-original-commit: 912e849207709b31aa11b7a2bec9ed8dd8b43203
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It is possible to define required fields from the Authorize.net backend
without which no customer profile can be created. These fields include
data that Odoo sometimes does not have at all (fax number, anyone?);
however including the phone number is a meaningful option.
Before this commit, if the 'phone number' was required by the
Authorize.net configuration and was correctly set in Odoo, this still
did not work because we did not include the phone number with the
customer profile creation request payload.
We do now.
opw-2215332
closesodoo/odoo#48420
X-original-commit: 034c04efa4ccecd40f657eae97ef2b04934d570c
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider a product P
- Let's consider that a draft SO has been created for P with analytic account AA
- P can be sold (sale_ok=True) and Re-invoicing policy = 'At cost'
- Untick the option 'Can be sold' on P
- Create an expense E for P with the analytic account AA
- Submit E and try to post the entries
Bug:
A UserError was raised saying that SO with analytic account AA must validated but
P is no more salable.
opw:2217773
closesodoo/odoo#48408
X-original-commit: 3db629cbcde9c4c3bbe2874c18e01dd31abe092d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The 'vendor bills' stat button on purchase order, once clicked, will
have a specific behavior depending on the invoice count :
0 : open a new invoice with pre filled fields (not saved yet)
1 : open the form view of the invoice
2+: open the list view of the invoices.
Before this commit, the invoice count was computed with an environment on
the current user. That means a record rule could make the invoice count
lower than the real count and so give an unwanted behavior. Ex: create a
new invoice even if there is already one created because the user cannot
see the other people's invoices.
After this commit, the action_view_invoice with make an explicit read()
in database to fill the cache with all the purchase order's invoices and
make sure the count is the real one.
Task : 2206969
closesodoo/odoo#48274
X-original-commit: e3101d92187946b2bd539e05956e4e83cd9c9097
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
jvm-odoo