Steps to reproduce the bug:
- Let consider a user U from a single company C (Multi companies = False)
- Let's consider a BOM B for a finished product FP with product P1 as component and product P2 as byproduct
- Let's consider that P2 is tracked by lot
- Log as U and create a MO for FP
- Produce the MO
Bug:
A widard was opened but it was impossible to create a lot for P2
opw:2216028
closesodoo/odoo#48556
X-original-commit: 30ebdee091362b8c857bdcad2bdf44bd698572c4
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Creation of production order from a bom with 0 quantity to produce will
fail. As there is already a constraint on the quantity to produce on MO,
this commit adds the same constraint on BoM.
closesodoo/odoo#48485
X-original-commit: 1330500885ae096372ab32fba4ffc9db252dd2d4
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a new course;
- Add content line;
- save.
Before this commit, Odoo raises an invalid field error on 'Course' which
is empty. If you try to select the newly created course, it is missing
in the list.
Now, the course is removed from the view when creating a new content
from a course. But it stays if the content is created directly from the
content menu.
opw-2210360
closesodoo/odoo#48534
X-original-commit: f0b616348f11e00aae8c9b30df4c0ed922041b26
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
added test case for text paste in autocomplete in the searchbar using mouse,
it should populate the autocomplete dropdown.
task-2204174
closesodoo/odoo#48251
X-original-commit: 010961ee3eac55a1e885ce918b597943078324f6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Create a new contact with:
- Name [DEMO]
- VAT RORO790707I47
- Country Mexico
An error inform the user that the vat is not valid, this happens because
the vat number is recognized as romanian and compacted before passing
to actual vat checking. Skip the check if the country of the new
partner does not match what is detected on the vat, assuming the user
know what he/she is doing
opw-2218491
closesodoo/odoo#48273
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Now we have the mobile search_panel in enterprise,
this commit simply adapt the Odoo repos part with:
- Css Clean up
- Remove the no longer existing step inside the tour
the button 'o_enable_searchview' no longer exist
inside a M2X dialog
Task ID: 2200099
closesodoo/odoo#48376
Related: odoo/enterprise#9494
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Bug
===
In ffe1d4047d "onchange" were replaced
by computed fields. But in 950296f661499f499b0a5776ce7fd91a66c2a63f,
they use manually this onchange method in the copy, which is not needed
with computed field (bug introduced certainly during a forward port).
Task-2226235
closesodoo/odoo#48531
X-original-commit: 63712e106dfae6ef99d93a0ba2ff4102ed430719
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
journals that were not of type sales and journals.
We update the hence of the view to take into account the original
invisible domain plus the domain we need for journals that use documents
closesodoo/odoo#48526
X-original-commit: 085fd43fd0b8a13dd713fbb4e34126ebe63ea504
Signed-off-by: Josse Colpaert <jco@openerp.com>
During the recent refactoring, the order reversal of the post messages
was dropped by mistake;
closesodoo/odoo#48523
X-original-commit: cffe6c305a64abfcc7a10fd8ab837398915ed906
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
This commit applies conditional questions management on the
"_get_next_page_or_question" method in "page_per_section" questions layout.
We choose the first section that has at least one active question when
searching the next section to display.
Indeed, a whole section could contain only disabled questions based on the
previously selected answers of the attendee.
(The logic is obviously reverted when "go_back" is True).
PR #48442
Task ID 2208574
This commit fixes 2 small problems when the user goes back on the survey form:
- The back button should not be shown on "page_per_question" layout if we are
on the first page of the survey.
Pages can be displayed on "page_per_question" layout if they have a
description since #44271
- Can't go back on "page_per_section" layout if you are on the second page of
the survey, introduced by 0675d68afb
LINKS
PR #48442
Task 2208574
This commit remove unecessary array around triggered_questions_by_answer values
that is used at the client side to find inactive questions.
Before this fix, when looping through every elements of
triggered_questions_by_answer, we got an array, instead of each question id
separately.
PR #48442
Task ID 2208574
We now have a way to display "free text sections" during the survey flow.
(Since 5b74f54396 )
However, the behavior during survey sessions was not optimal:
- Attendees could click on "submit" and it would raise an error
- The section description was not displayed on the host screen
- The section description was never the "current question" of the session of it
was the first item of the question_and_page_ids
This commit fixes all those points to have a nice session flow.
While the host is explaining the section description to the attendees, they get
a waiting message on their screen.
In addition, we fixed the display to avoid showing pages that lack a
description, and we reworked the '_get_pages_or_questions' method to have more
meaningful and readable cases for every layouts.
LINKS
PR #48442
Task 2208574
This commit fixes a problem where the "final leaderboard" would duplicate the
attendees ranking display if the last question of the survey is scored.
We now also directly close the session when the host hits "next" on the last
question and there is no leaderboard to display.
LINKS
PR #48442
Task 2208574
This commit fixes the faded out answers bars on choice questions during a
survey session.
The logic is currently inverted (correct answers are faded out instead of wrong
ones).
LINKS
PR #48442
Task 2208574
There is a discrepancy between what country is used to compute the
fees for a transaction depending on where we are in the payment flow.
At rendering, the country of the order's shipping partner is used (since
it is set as the main partner in the rendering values dict through
`render_sale_button`).
At creation, the country of the partner is used (since the
`payment.transaction` record is created with the order's main
`partner_id` in `_create_payment_transaction`).
This is unfortunate and can cause issues with payment flows if there is
a mismatch between countries of the shipping/invoice/main partner, as
the fees may be computed as 'international' in one case and 'domestic'
in another - this causes the values sent to Paypal to differ from those
saved on the transaction, which causes the transaction to be rejected
upon return from Paypal because of an amount mismatch.
Since the transaction is created using the main partner of the order,
I believe it is preferrable to use it for the rendering as well. Some
may dislike this choice, as it means that if you use these fees to
manage your delivery fees, a customer with a shipping address to is not
the same as the company's country will pay domestic fees, while they
should pay international ones. However, this is mitigated by the fact
that:
- this did not work before this commit (hell of an argument)
- the delivery module is there to handle those cases with much higher
configurability
- having a consistent computation is more important than managing this
case
opw-2225023
closesodoo/odoo#48519
X-original-commit: a8689769afa22fb633f2e911f1a4dea6caa193d3
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Change icon for documentation link to fa-question-circle in green.
Task ID 2226026
closesodoo/odoo#48469
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, tours were activated in a non deterministic way and there was
no way to control the order.
Now there is a `sequence` key in the options dict (i.e. the second parameters of
`tour.register`) which will determine the tour sequence order, the lowest being
first and going upward. Unsequenced tours will behave as before with no particular
order.
Task 2191192
Issue
- Install Mass Mailing
- Activate debug mode
- Create a mass mailing
- Select any template
- Go in codeview
The snippets hide a part of the code
Cause
When toggling the codeview, we apply
a position absolute (all to 0) which
shift the #wrapwrap
Solution
Add an intermediary parent and apply
position relative to #wrapwrap like
in 12.0
OPW-2220639
closesodoo/odoo#48496
X-original-commit: e415cffa2ffb3fe4b5f0e32bd96b3433387a95e3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Before this commit, creating a new email template from the field
didn't have a default model
In this commit, event.registration is set as default value for
model_id on new templates
closesodoo/odoo#43606
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the account on the original line was replaced by the
accrual account. This could be problematic for hashed journals. Instead
of having 2 different behaviors for hashed/non hashed journals, we
decided to always create 2 journal entries, which is also more academic:
* We don't replace something on an entry that has been posted
* We don't end up with taxes on the accrual account
* Accountants are used to do it this way
closesodoo/odoo#42787
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Commit https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72#diff-e4ca107fe5c84ec39ba346fb90d1bdf6R76
added strange code affecting the whole editor when website_blog was
installed. To stay consistent, commit https://github.com/odoo/odoo/commit/80f54f563a3917828c5f67dfe9c44d0f6b0c5324
moved it in standard website and marked it as to review.
It is in fact the cause of a bug: *all* drop areas appeared with a big
editor text "Drag and drop a building block here" because of this code.
As a fix in stable, the problem was solved so that the code works as
intended: adding an editor message on a normal .oe_structure makes it
an .oe_structure.oe_empty automatically. Here in master, this code will
simply be removed and it will be up to the devs to not make errors in
their xml so that the editor messages appear. This commit in fact
keeps the "removing spaces" feature and enables it for all oe_structure.
Related to task-2210733
closesodoo/odoo#48463
X-original-commit: 5381e9d900b344e7d48a6b347c5fc551d433b15e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit it was difficile to express xpath into these
group elements. By setting a name on the elements we no longer need to
use indexes or longer xpath expressions and can easily xpath on the
element itself right away. This will be more tolerant to form view
redesign.
closesodoo/odoo#48083
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the same xml file (meaning one of the two rule is useless, or wrong
if giving less rights than the other).
Removing rules that had no impact will ease the understanding of
security problems, by reducing the number of interconnecting rules.
From opw-2200219 opw-2210285 (v12)
Use case (2200219):
- Install CRM, sales and Automated Action
- Create the automated action
* Model -> Sale Order
* Trigger Condition -> On creation
* Action To Do -> Add followers
* Add Channels -> sales
- Create a new CRM opportunity with a partner set, Save
- Click on the "New quotation"
- Save
A Traceback "Error: A follower must be either a partner or
a channel (but not both)." will popup, blocking the user from
completing the action.
Use case (2210285):
After adding a channel as a follower to a sales team it is not
possible to create a sale order from a contact or opportunity. You can
only create a sale order from the sales app in that case.
End of use cases-----
This occur because the context flag default_partner_id is used by
the model to override the empty partner_id which should remain empty
Fixed in v12, forwarding the test for v13 and upward
closesodoo/odoo#48476
X-original-commit: 049aa5c2297938bcd378d1dee1aa766a646cb461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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>
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>
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
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>
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>
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
Laurent Smet