The language code was corrected in #32868 and backported in saas-12.2 via #33040
However a partial fix was also done in stable versions, and overrode the
final fix in 12.2 by mistake during fwd-ports
(fd0a10026c).
This commit reapplies the change from
91b6c1076c in saas-12.2.
Closes#32868#33040
Until know, we suppose that
<div id='first' class='col-1'><div id='second' class='col'>
will be on the same line, with the second div that take the left space.
But that not the case, if you don't force the second to col-11 and that the
content is too long, if will show the div like a col-12 instead of a col-11.
Their are probably others case in the migration of bs3/bs4 to handle.
+ add word-wrap on the question to avoid long content that have overflow
below the right column.
Commit 0a76be7 fixed a duplicated xml id but forgot
to modify views inheriting the corrected xml id.
closesodoo/odoo#33377
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- There's a constraint limiting the number of contracts an employee can
have.
This constraint take in account closed contract which cause issues.
For example if you have to sign a new contract for an employee with a
running contract, you'll have to close the current running contract.
But if this employee already has closed contracts, you won't be able
to close it since they are detected as ""running"" contracts.
closesodoo/odoo#33294
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
When trying to remove a format (bold, italic, underline), collapsed at
the start of the DOM, an error occurred because of a wrong range.
Ex.: `<p><b>Odoo</b></p>` -> when clicking before the word "Odoo", then
clicking the "bold" button, we expect to be able to start writing in
plain (not bold) text (for that, the DOM has to look like this:
`<p>\u200B<b>Odoo</b></p>`). We now have that proper behavior without
the accompanying error message and loss of selection.
Task ID: 1978515
closesodoo/odoo#33038
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Steps to reproduce the bug:
- Create a new profile P with "free signup"
- Log with P
- Go to website profile of P
- Send an email to valide the email of P
- Click on the generated link in the verfification email
- P is able to edit his profile
- Open a new session with P
Bug:
P was not able to edit his profile because the variable "validation_email_done" is
reset to False. Now the karma on the user is checked (inspired from website_profile
in template "email_validation_banner")
opw:1984576
closesodoo/odoo#33335
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Since the performance commit @c42ccf2ca7f0a600a0dd7e3b4dd8bacd7a5c6513
the lunch products are displayed only if you have already ordered it.
- Added indexes on `lunch.order` to speed up the SQL request.
closesodoo/odoo#33336
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Even if data is not really sensitive, there are no reason to let it public.
closesodoo/odoo#33326
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
added 5% tax rate for sale and purchase which was missing
was task# 1915454
closesodoo/odoo#33400
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
1) In the settings of project, enable sub-tasks.
2) Create a new project with a sub-task.
3) Create a new product (type service).
4) In the "Sales" tab of the product check the "Create a new project
but no task" in the service tracking options and select the created
project as project template.
5) Create an invoice for that service and confirm it.
The sale order is set on the tasks of the duplicated project but not on
the sub-tasks.
The `write` mechanic is override in project.task to apply modifications
done on the parent task to its sub-tasks. The method
`_subtask_write_values` is used to gather `{field: value}` pairs and
update the sub-tasks. That method is override in `sale_timesheet` in
order to force the `sale_line_id` to `False` when the project is
duplicated because the duplicated project is not attached to the sale
order of the original model.
The fix has been re-write the `sale_line_id` value on sub-tasks.
opw-1985484
closesodoo/odoo#33416
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
The field website_published is not ensured when module portal
is installed because the module portal doesn't depend on module
website_mail.
PS:The module website_mail depends on the module portal because
website_mail depends on website and website depends on portal.
opw:1997478
closesodoo/odoo#33452
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The rte_translator tour that test translation on the frontend could not
be started from the "[debug menu]" > "Start Tour" for two reasons:
- the start URL is not specified, so the test was started on current
backend page wich is wrong (in python the start url is "/")
- the backend original state (params after #) does not work with ?k=v
inside argument value, so `#return_url=/?debug=true`.
To solve this issue, we encode the return_url value and add a start url
when rte_translator is started manually.
opw-1998623
closes#33443
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create a tour with only one step for Community
`edition: 'community'`
- Install a database in Enterprise
`tip.in_modal` in `_check_for_tooltip` cashes since `tip` is undefined.
opw-1998603
closesodoo/odoo#33430
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Include the Google Error message in the error message showed on screen.
Fine tuning of da13c70484 : missing transiflex translations, empty body,
wrong string format.
opw-1966309
closesodoo/odoo#33216
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The snippets "Latest Posts - List" and "Latest Posts - Big Images" have
a "Number of columns" options but:
- these snippets are not taking the option into account and are
specifically size (in large "list" => 100% width, "big image" => 50%)
- the snippet content is dynamically generated, so the column sizing
set on preview when saving is lost when content is displayed
- the option "Number of posts" contradicts the option
"Number of columns" and can leads to have several lines that are not
taken into account in "Number of columns" (the column number is the
number of child)
Thus, this changeset disable the option for these snippets.
opw-1984899
closes#33393
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Fine tuning of 5ef86ef6c874ab4dc78402493d05b2460c69e7f6
Steps to reproduce:
Set a custom language settings for date by switching the %m and %d.
Create a sales order
Current behavior:
Invalid date error boxes was raised two times
fixes#33408
opw:1998971
closesodoo/odoo#33415
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When a leave type is in hours, before this commit:
- in the leaves request list the request duration is shown in days.
- the name of the leave shown duration in days.
- the rounding after the conversion from hours to days, generates some
misunderstandings. If you have a day of 7.5 hours, and you take a leave
of 2 hours, it would be round it to 0.25 days, and not to 0.27 days as
it should be. This occurs because we round to the 1/16 of the day.
Now:
- in the leave request list, the request is shown either with days or
hours depending on the leave type.
- the name of the leave shown duration either with days or hours
depending on the leave type.
- the leaves are shown in the correct unit, there is not more
misunderstandings occurring because of the rounding.
related to commit : 5c33ebef5f and 2c366acbf0
opw-1974691
closes#29804closes#33290closesodoo/odoo#33369
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate online payment of invoices
- Activate and configure Stripe
- Create an invoice, access it through the portal
- Pay it with Stripe
The user is redirected to `/my` instead of `/my/invoices/<id>`.
The root cause is because Stripe creates 2 transactions, the second
being created at:
https://github.com/odoo/odoo/blob/43295c2a3741fb98f9c5d1a506652442efed0a82/addons/payment_stripe/static/src/js/stripe.js#L108
This second transaction, which is used to record the payment, doesn't
contain the appropriate `success_url`.
The best fix would probably be to either:
- prevent the creation of the second transaction by refactoring
`stripe.js`
- pass the appropriate `success_url` to the `stripe_form` template
- reuse existing draft transactions instead of creating a new one
None of these solutions is really suitable for stable since it might
require some heavy modification. However, a simple workaround is to
change the fallback `success_url`since we have all the necessary information
to build it.
opw-1997283
closesodoo/odoo#33404
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to the website settings and activate the option 'Tax-Included' for
the pricing in the website.
- Go to Sales > Configuration > Delivery methods and create a new method
based on rules. For example:
Price is 10.0 when the weight <= 100
Attach a product (with taxes) to it.
- Publish on website
- Buy a product on the eCommerce
- Checkout, go up to payment step and choose the delivery method created
The 'Delivery:' field on the left shows the delivery price with taxes
excluded although they are included. Funny thing: going back to the
'Address' step show the correct price.
This is because the `delivery_price` field does not take into account
the tax configuration.
We can use the `amount_delivery` field (hum hum) which does it
correctly.
opw-1981808
closesodoo/odoo#33394
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install discuss, change the general setting in dev mode to disable the
"Show Effect" checkbox. Change the preferences of the user to let odoo
handle notifications. Ask another user to ping you on a chatter then go
to discuss and click the "Mark as Read" button. Traceback.
The `notification_manager` agent has been replaced by another agent in
07cd24b1ec, the code has been updated to use the new agent.
opw-1986844
closesodoo/odoo#33363
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This reverts commit dbaef7de17 since it
causes issues (unbalanced moves). Temporary revert so we have time to
analyze the issue.
opw-1997794
closesodoo/odoo#33380
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Go to any field Date
- Enter wrong date
Bug:
A traceback was raised.
Now a warning is raised and the wrong value is removed.
opw:1974747
closesodoo/odoo#33362
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit and since 2f7c03d9ca, the admin user has not ID=1
anymore.
Thus, some old condition were not doing what they were expected to.
Firstly, the admin was not considered as such on the forum, and if its karma
points were not high enough, it would not be possible to do anything for the
admin. Note that it was fixed in saas-12.1 with 1dac413130
Secondly, some _search functions would not return a truthy value anymore.
closesodoo/odoo#33359
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit 98ee15977a made the Stock Interim accounts reconciliable,
and introduced auto-reconciliation of related entries. This has the
advantage to clean-up entries in these accounts. However, since these
accounts are reconciliable, the entries will show up in the manual
reconciliation widget (expected) and the bank reconciliation widget (not
expected).
There are 2 cases where it causes issues:
- after migration from v11, the entries were not reconciliced. Although
this will be fixed in the near future, it is too late for already
migrated databases
- using MRP. A list of components i costing Xi might be used to create a
finished product of cost Y != sum(Xi). Indeed, the routing cost has to
be taken into account. In this case, the entries are not fully
reconcilied.
The result is that the bank reconciliation widget ends up with an
growing number of unreconcilied lines, and in the end making it
impossible to use.
In order to work around the issue, we prevent any account used as a
stock interim account to be included in the bank reconciliation widget.
For performance reasons, we directly search the `ir.property` table for
the corresponding accounts instead of filtering AML thanks to
`excluded_ids`.
Closes#32611
opw-1963025
opw-1967462
closesodoo/odoo#32957
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When using `sales_team.team_sales_department` as fall back default
team, last condition that checks if such team can be default was
incorrect, because `active` value check was mixed with lead type check.
In other words: True or False and False => True
But intention is: (True or False) and False => False
opw 1997715
closesodoo/odoo#33316
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The field session_ids is fetched from the server for what seems to be no
good reason at all; for database with a lot of sessions (test case with
40k+ sessions), this can lead to an extremely slow dashboard.
closesodoo/odoo#33303
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do a PO in a foreign currency
Invoice it in the same foreign currency
Validate the invoice
Before this commit, The account move of the invoice
contained a price difference line
which is wrong, since the price has not changed in any ways
After this commit, the move has only two lines
one in the stock input, one in the payable
Also, the case where the price does change
due to a change in currency rate is handled
OPW 1955315
closesodoo/odoo#32616
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
* Some accounts have wrong tax tag mapping
* Some fiscal positions don't work properly (mapping of taxes, right tax
keys, right accounts)
* Missing fiscal position "domestic partners" in order to allow
automatic selection of the right fiscal position if it is a doemstic
partner and to make it more clear for customers, otherwise they might
wonder why fiscal position field is empty for domestic partners.
* Issue with fiscal position "Geschäftspartner EU (ohne USt.-ID)" to
detect the right account, tax, tax tags if we sell to a customer / buy
from a supplier located in the EU without valid VAT-ID (for example
private people)
* Issue with fiscal position "Geschäftspartner Ausland" to detect the
right account, tax, tax tags if we sell to a customer / buy from a
supplier not located in the EU.
Closes#31389closesodoo/odoo#32673
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase to reproduce
- Create a BoM with finished product A and Comp C
- Create a RR on product A with min qty 10
- Product A is tracked by serial number and have route manufacture
- Run the scheduler twice.
The finished tabs in the manufacturing order created from the order
point contains 10 move lines with 1 qty reserved and 0 quantity done.
The first run created the MO. The second run, assign the finished moves
and thus created the move lines for finished product A.
However those move line are not used by mrp because the workorder and
the produce wizard will only create new lines instead of using existing
lines with reservation. Also action_assign on MO only trigger
_action_assign on raw moves.
This commit add a hook on scheduler in order to modify the domain that
will be used in order to search moves to assign. Use the hook in order
to avoid move with the production_id many2one set.
closesodoo/odoo#32597
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Open a quotation from the portal using IE11. The sidebar is rendered as
it did not have any width.
What we are trying to achieve on large screens is to create a sidebar
with a fix width the size of its children and to let the rest of the
content (right to the sidebar) expands. On small screens we want to
invert the direction from left-to-right to up-to-bottom.
The classes `col-12`, `col-lg` and `flex-lg-grow-0` are used to fulfill
that purpose.
The problem is due to the rule `flex-grow: 0 !important` applied by the
selector `.flex-lg-grow-0` on the sidebar. On Chrome/Firefox the dom
element takes the width of his children as minimal width, the
`flex-grow: 0` does not shrink the element below that minimal width.
IE11 does not set a minimal width based on the child elements of the
node, the width is equal to 0 and the `flex-grow: 0` forbid it from
growing.
The solution is to replace the said classes by the `col-lg-auto` class
that does exactly what we want and is cross-browser.
opw-1944188
opw-1935087
closesodoo/odoo#32484
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 10.0 that would be Debian 8
(jessie) and thus Jinja 2.7.3 (albeit with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32602
Signed-off-by: Christophe Simonis <chs@odoo.com>
When creating a delivery product from the delivery carrier form.
The delivery product should not be sealable or purchasable.
opw-1958029
closesodoo/odoo#32289
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In this way the description of the delivery method can be used on a SO
line. If the description wasn't set, the name of the delivery method
will be used.
opw-1958029
On the ticket 1961412, the custommer has more than 12 millions
of stock moves. Before this commit, the search request does
not take too much time to execute but fetching the fields on the
recordset takes a lot of time due to the 'in' in the where clause
of the associated SQL request.
This optimization permit to avoid this 'where clause' and decrease
the time to gather all the different fields. The time has been reduce
to less than one minutes where it takes approximately 20 minutes before.
closesodoo/odoo#32520
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 11.0 that would be Debian 9
(stretch) and thus Jinja 2.8 (with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32601
Signed-off-by: Christophe Simonis <chs@odoo.com>
This revision is similar to
605b94e64c
except that instead of an OperationalError
(e.g. a conccurent update),
this is an IntegrityError which is raised,
an sql constraint which is not met,
e.g. a unique or required constraint.
In the case of this opw,
this is the picking name unique constraint
which was not met,
the picking sequence number has somehow been re-used.
Both
`psycopg2.OperationalError`
and
`psycopg2.IntegrityError`
inherits from
`psycopg2.DatabaseError`
We therefore choose to use this Exception class,
to include all kind of psycopg2 exceptions that prevent
the transaction to be committed.
opw-1965679
closesodoo/odoo#32577
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Olivier Dony