Issue
- Install eCommerce & Delivery Costs
- Add a delivery method for US only
- Publish the delivery method
- Logout
- Order something, select your delivery method
and pay with wire transfer
- When it's done, click 2 times on the browser
back button
Traceback
Cause
When going back, the address is incorrect
(public user address).
So since you have 2 delivery methods and
your address have only one, an assert
cause a traceback
Solution
This is the right behavior but I think
it's better to give a clear error message
instead of a traceback.
OPW-2243736
X-original-commit: 0222b727c143593debaf40a4ab54bda2f6b42213
View rendering from javascript has recently been made to check
permissions (See commits 64d0dab0a6
through ccc98e0169). Some assets required
by the iframe editor are rendered in JS so that they can be injected
into the iframe, but their permissions had not been updated, causing a
crash when trying to create or edit a mass_mailing campaign.
This commit fixes that by adding groups="base.group_user" to the
required templates.
closesodoo/odoo#51598
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
The `display_name` of the product was showing the code in the "Recently viewed products",
the code value isn't needed to be seen in the website.
After this commit:
More user-friendly product name is shown
OPW-2258774
closesodoo/odoo#51719
X-original-commit: be4d0d58081bea1b75ceee8f90372ed8cedbee2e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when the user tries to create a new quant, even if
the product doesn't use an expiration date, he/she will not be able to
create the quant.
The issue was as `removal_date` field is added by `product_expiry` in
the quant list view, the field is on the values used to create a new
quant but not in the list of accepted field for quant creation.
So, it raises an UserError.
task-2260085
closesodoo/odoo#51482
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The _view_get function is a recursive function used to retieve all the
views related to a view (inherited or t-called).
The issue is that by an odd set of circumstances it is possible to have
a loop in the view graph. Resulting in the recursive function being
called until a "maximum recursion depth exceeded" error occurs.
Example of a loop: A t-call B and A inherit from B
This is possible on an update of a view that has been forked by website:
If the view A was doing a t-call on B and is has been duplicated with
the arch modified.
When we update with the changes A now inherit from B instead of t-call B
Since the arch was modified it will not be updated so A will still
t-call B but the inherit_id of A is unchanged so it will be updated to
reference B resulting in a loop.
closesodoo/odoo#51620
X-original-commit: 63e1e84ebd7e609d6e06d83dc0f0092688b013eb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, block for adding new Shipping address was always visible even if It is disabled/Not needed.
With this commit, We respect website configuration (Website --> Configuration --> Shipping Address) to display this block.
closesodoo/odoo#51732
X-original-commit: da9d9d039bfd0ca2a7e27671ac61a0b557d531d5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, when a SysTray dropdown is open the user can scroll
the element behind the dropdown.
After this commit, we disable the scroll until we close the dropdown.
Steps to reproduce:
* Open Odoo on "Mobile"
* Open the Activity SysTray
* Scroll the "NavBar" menu (=> Bug)
Note this fix is also applied in Desktop, as for me the "NavBar"
shouldn't never scroll on Desktop.
Task ID: 2231956
Task ID: 2234042
closesodoo/odoo#51716
X-original-commit: 7bb155991b9daec37edf73ef90cbad26268d76bb
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
- Confirm a Sale Order with a Customer Reference ('client_order_ref'
field) set;
- Validate the Delivery Order;
- Print the Delivery Slip report;
The display area of the Customer Reference field is not correct on
the printed pdf report
opw-2260756
closesodoo/odoo#51701
X-original-commit: 4f3a9a59394cac425e23b81b3fe811a592c6dae2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a promotion program with conditions:
- Minimum purchase in currency (ex 100$ tax excluded)
- Auto apply
- On current order
- Unlimited use
And reward:
- Free product
- 1 Quantity
Go to website shop. Fill an order with amount above the minimum
required by the program. The promo will apply and add the free
product.
Increasing the order amount will eventually make the free product
quantity increase, eventually overcoming the reward product
quantity.
Fixing by calculating the reward quantity using both minimum quantity
and minimum amount and using as cap the to reward product quantity
currently in cart
opw-2246138
closesodoo/odoo#51680
X-original-commit: 02331a34cf66117b27cfa1e96078b4721cbd1e70
Related: odoo/enterprise#10722
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The `@api.model` decorator prevent the call to the method from a button.
opw-2262445
closesodoo/odoo#51686
X-original-commit: 7de8420f2b645849a953376d6b1d8d663f3c8aa2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The button `action_open_product_lot` is added by the view `product_product_form_view_bom_button`.
Both the current view and the view `product_product_form_view_bom_button` inherited
from the view `product.product_normal_form_view`,
without any priority specified.
In order to make sure the button `action_open_product_lot` is in the view
when the view `product_product_form_view_bom_button` is loaded,
you either need to directly inherits from the view holding that button
`product_form_view_procurement_button`
either you need to increase the priority of the current view
so `product_product_form_view_bom_button` is loaded in priority.
Same thing for the view `product_template_form_view_bom_button`
Upgrade Request 47960
```
ValueError: Element '<xpath expr="//button[@name='action_open_product_lot']">' cannot be located in parent view
Error context:
View `product.product.procurement`
[view_id: 783, xml_id: mrp.product_product_form_view_bom_button, model: product.product, parent_id: 319]
```
closesodoo/odoo#51655
X-original-commit: 26fac2af85acb0ae9f9e479aec5eb16930d69e49
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Make sure a value is always set for the field `destination_account_id`.
opw-2254722
closesodoo/odoo#51615
X-original-commit: 9e68ec931d254ba563b4a16afa38b6003336a7cf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
On the hr_recruitment application, when archiving an employee, a
wizard pops out to ask the reason (fired, left, ...).
When archiving all the record of a column, instead of retrieving
the dbID, you get an action targeting the wizard model.
No need to call updateColumn at that time, as this will be done
when closing the wizard.
So adding this small condition fixes the traceback and changes
nothing on the flow.
closesodoo/odoo#51609
Taskid: 2259776
X-original-commit: a5b84b807be51c46f09e2103c107f4232e446bda
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Task 2201948
*These actions were either unused or only used in enterprise modules.
The first ones have been deleted, and the second ones have been move to
the corresponding enterprise modules.
* account.fiscal.year: the whole model has been moved to enterprise
closesodoo/odoo#46110
Related: odoo/enterprise#8706
Related: odoo/upgrade#1083
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this change the map view (the fix could also be in web_map module
but currently all dashboard fixes are at the same location) would have
a zero height so it was not shown at all in dashboard even if it was
loaded.
With this changeset, we set a 100vh height (total height of viewport).
opw-2257146
closes#51610closesodoo/odoo#51631
X-original-commit: c5bd63f60c8e34d8a947a6e4118ce707a2a894a6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit there was a traceback when rendering the lightbox
in the gallery snippet. This bug was introduced by the new media dialog
system.
Related to task-2162952
closesodoo/odoo#51603
X-original-commit: 791ecf72af4a0928a02bf1bbdc269c67fcc3524c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In odoo/odoo#38950 the navbar was reworked such that there is only one,
instead of using two different copies for when the user is at the top of
the page vs when the user has scrolled a little. The transition
animation to the next blog post used the first navbar's top offset to
compute where it should scroll, which is no longer correct.
This commit fixes that by using the content's offset instead, which
should always be correct.
closesodoo/odoo#51599
X-original-commit: 85cc286ff7b04eaf624082b761e14bbdde50ac76
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
PURPOSE
We are currently working toward turning every user avatar (i.e. the round
picture of the user) in a shortcut to open the chatbox to that user. It only
makes sense to also have the user avatar in the header of the chatbox
(like in Facebook)
SPECIFICATION
Replace the current IM status colored dot of the chatbox header by the same
avatar/im_status compound currently used in the chatter.
LINKS
Closes https://github.com/odoo/odoo/pull/51258
Task-2256061
closesodoo/odoo#51258
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This lib is also used by the Gantt view, so we move it to the
common basis between web_editor and web_gantt, which is web.
Part of task 2205607
closesodoo/odoo#51606
Related: odoo/enterprise#9740
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
price_subtotal and price_unit shouldn't be used on tax lines. While it might seem to be always set by the code on those lines, it is not intended to work this way ; which is why migration scripts sometimes let those fields blank on such lines. Before this fix, such migrated databases always had a tax amount of 0 shown in amount_by_group, which was of course wrong.
closesodoo/odoo#51563
X-original-commit: d3b810de3680acba3e2587111f58a33ad5c29fb6
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
PURPOSE
Currently, the activity dropdown displays the activity types of activities.
The goal is to display the activity summaries instead, and fallback on the
activity type if there is no summary set.
SPECIFICATION
In the activity dropdown, display the activity summary instead of the activity
type. Only display the activity type if there is no summary set on the activity.
A long summary will be ended with a ellipsis.
Here, handled a long summary for chatter, list, kanban, and activity views.
LINKS
Task: 2254893
PR https://github.com/odoo/odoo/pull/51438closesodoo/odoo#51438
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Using Email Marketing or Marketing Automation without website installed will
not populate the links for your social media accounts.
SPECIFICATIONS
Move social_links template directly into mass_mailing and use company
information available through social_media module as default values, then
overridden by website information.
TaskID 2036094
PR #51025
Enterprise PR odoo/enterprise#10497
Related: odoo/upgrade#1212
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
=======
Since V13.3, the product "Taking care of Trees Course" has a Service Invoicing Policy
configured as "Milestones (manually set quantities on order)".
So, it's not possible to create an invoice from a SO.
SPECIFICATION
=============
The policy should be Ordered quantities
Taks ID: 2248213
closesodoo/odoo#51583
X-original-commit: 4883a4fa14dea966df2469ce6bc6cbc5cf5ee8c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Instead of merging Query objects (main domain and access rules domains),
which requires renaming aliases in query strings, make `expression` push
its result in an existing Query object. This removes tricky code.
This also avoids using `IrRule.domain_get()`, which has become unsafe,
since it returns a list of tables (for the FROM clause) which does not
include the joins from the generated Query object.
closesodoo/odoo#49999
Related: odoo/enterprise#10126
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Use a LEFT JOIN on table `ir_translation` instead of a subquery, by
using the same implementation as the one used for ordering by a
translated field. In particular, this avoids having both the LEFT JOIN
and subquery when searching and sorting on a given translated field.
This fixes some cases where search results are actually missing. For
instance, searching with a domain like
['|', ('parent_id.name', '=', 'foo'), ('name', 'like', 'foo')]
where `parent_id` is auto-joined, misses results where `parent_id` is
NULL, because the actual query makes cartesian products for auto-joins:
SELECT "res_partner".id
FROM "res_partner", "res_partner" AS "res_partner__parent_id"
WHERE ("res_partner"."parent_id" = "res_partner__parent_id"."id")
AND ("res_partner__parent_id"."name" = 'foo' OR "res_partner"."name" == 'foo')
Using LEFT JOIN instead of cartesian product above, the query includes
all results where `parent_id` is NULL:
SELECT "res_partner".id
FROM "res_partner"
LEFT JOIN "res_partner" AS "res_partner__parent_id" ON
("res_partner"."parent_id" = "res_partner__parent_id"."id")
WHERE ("res_partner__parent_id"."name" = 'foo' OR "res_partner"."name" == 'foo')
The management of the join contexts now relies on the `Query` object,
that has all the necessary logic to do so. The refactoring also removes
the class `ExtendedLeaf`, which is no longer necessary: the join
contexts are all managed by a single `Query` object, and the parsing
stack now only contains triples like (leaf, model, table_alias).
Also inline directly the SQL translation made in `_to_sql`, which
overall simplifies the management of SQL parameters in the domain
compilation. The algorithm is illustrated in the code itself.
Before this commit, a `search_count` was preparing the ORDER BY clause
even when not using it. The ORDER BY clause generation can introduce
some JOINs in the query, which are useless when the ORDER BY clause is
not used, like in the case of `search_count`.
... instead of public user
Once sending the template email Coupon: Send by Email.
Odoo was sending to the partner linked to the sale.coupon
However in the case of the program having the parameters:
apply on next order & apply automatically.
The partner_id.id is the public user.
This commit is modifying the value of the template to send
the email to the partner of the SO instead of the partner
of the current coupon.
opw-2255674
closesodoo/odoo#51570
X-original-commit: f7e0c2d1568b222d510d3a10fba1116fabfff604
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Get rid of email / phone behavior on lead that is hard to understand: if
and contact is set fields are readonly, if not they are editable.
SPECIFICATIONS
Track partner update of email and phone field. Now, when an user writes on the
email or phone of a lead, it also writes on the partner. That is why we want to
track those fields.
Task ID 2207636
PR odoo/odoo#48395
Related: odoo/upgrade#1025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Get rid of email / phone behavior on lead that is hard to understand: if
and contact is set fields are readonly, if not they are editable.
SPECIFICATIONS
We want to be able to edit them if a partner is set. If we write on the
email/phone of the lead, it should write on the partner (and vice-versa).
Even a Falsy value is propagated to the customer. Reason is that if you update
a contact information, it should be available for all other records. Setting
a void value probably means you want to stop contacting this contact. This is
now also propagated.
SIDE NOTE: MOBILE FIELD
Mobile field is a bit different. Main phone contact field is phone, and is
placed in the main contact section of the lead view. Mobile is under a more
technical / detailled tab and is not completely synchronized with the partner.
Like zip, city or country, changing partner updates lead information but
changing lead values does not propagate those to the customer. Those fields
can be used for deal-specific information if needed.
Statistics: 5k crm.lead use mobile for 80k active records which means it is
a "lesser field".
LINKS
Task ID 2207636
PR odoo/odoo#48395
Upgrade PR odoo/upgrade#1025
DE CREDITO ELECTRONICA" A and B.
closesodoo/odoo#50508
X-original-commit: ce45b1cf463e0874f65dce0ba78c7fac0127d639
Signed-off-by: Josse Colpaert <jco@openerp.com>
When a theme module is updated the changes made on a view are considered
as user changes, prenventing the view from being updated in the future.
Fixed by comparing the arch being written with the arch of the original
view. If it is the same the record should not be noupdate.
Plus added a test to make sure the theme views receive theme updates
after being updated once.
Introduced by: https://github.com/odoo/odoo/commit/4acf177b4c55f3a16362cbeafea3d332ef4fe819closesodoo/odoo#51557
X-original-commit: 221470ab9c9eda3f3a4e2da0fa1a7bb23d6288cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Issue
- Install "Sales" and "eCommerce"
- Activate debug mode
- Go to Settings->Technical->Email->Templates
- Search and open "Sales Order: Confirmation Email" record
- Click on stat-button "Preview"
- Select a "Sale Order" sample with product(s)
The quantity column label is not in the right place/column.
Cause
Each row of the table is a table.
Solution
Add same fixed column size css on each table.
opw-2242914
closesodoo/odoo#51380
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When there is a:
`groups="..."`
on a qweb view, when you edit the view with the editor then save all
groups will be removed since they are processed (so either we don't see
`groups` in the rendered view, or we don't see the element itself).
With this change, the "where should this part be saved when edited"
branding will be distributed to elements with `groups` attribute.
Added test without change failed with:
AssertionError: {'data-oe-model': 'ir.ui.view', 'data-oe-id': '827',
'data-oe-field': 'arch'} != {}
because branding was added to `root` tag before change.
opw-2253576
closes#51489closesodoo/odoo#51548
X-original-commit: c77bd5b043b7d2a795d0fc70c8e83b308a357224
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
If we try to load a csv file with opening values for the anuaffected
earnings account, there will be errors because when trying to balance
the move, we filter the lines on that account and we don't expect there
to be multiple lines in it.
closesodoo/odoo#51401
X-original-commit: ad4277219fe078712916e91c1be566a9b412fe1f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Technically removing the entire thing if it's not one of the special
cases is a form of cleanup I guess, but that seems a bit brutal and
counter-productive. So that function should *probably* return the
input value if it's not a type which requires special processing.
closesodoo/odoo#51531
X-original-commit: b42994c87dce12c5ba22943f6cbe00240fe43138
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently if an event has tickets, some of them with start date and some of
them without, it is considered has beginning at the minimal start date.
However if a ticket has no start date and is not expired, it means it is
available for sale.
An event start date is therefore the first date of its not expired tickets if
they all have a date, otherwise it is set to False (aka, already started).
We also fix display in main event page: events not yet open are not considered
as Sold out or Closed anymore, just not yet open.
Task ID 2244487
PR #51503closesodoo/odoo#51523
X-original-commit: 8404a6ff12ee82e9b4ec35660f74dbe0b4a90cb0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current display of "You ordered more tickets than available seats" is quite
ugly, missing modal classes to make its padding pixel-perfect.
Task ID 2244487
PR #51503
X-original-commit: 14e510ee186c36d5bd723b3077d000122f7b181c
toggle_website_menu (in website_event_track module) is called by website_event
set_customize_options (in website_event module). Since website_event_track is
not installed by default when website_event is installed, this function might
not be available in the event.event model. Therefore toggle_website_menu has
been moved from the event.event model in website_event_track to the event.event
model in website_event.
Followup of bd99cc24b1
Task ID 2244487
PR #51503
X-original-commit: e541efe1338f853962560db4d982821707ddc3c6
jvm-odoo