Contracts are only accessible by managers which raise an exception in
_create_resource_leave if not sudo()
closesodoo/odoo#33613
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
lunch.cashmove.report only take into account orders that are ordered or
confirmed.
That means that in action_order we have to set the state to ordered
before checking the wallet content.
This will then raise the error and rollback the value
closesodoo/odoo#33583
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
For some Chome version (e.g. 74 chrome verion on Debian) the iframe
trigger 'load' event twice (one time for document and on time for body),
the widget must insert the content in the body. Before this fix, the
content are add only one time and are removed by the next iframe loading.
closesodoo/odoo#33561
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The added field `phone` on `res.users` shadow the field `phone`
inherited by `res.partner`.
The issue is that the field `phone` on `hr.employee` can be read only
by the employee or the HR team.
A lot of views tries to display the field `phone` expecting the one
declared in `res.partner` which should be readable by everyone.
But the one declared in `res.users` shadows it.
closesodoo/odoo#33569
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Reproduce:
Add multiple lines in the reconciliation widget
Try to create a new one and edit it
Problem:
A constraint checks that all the lines have the same value for To Check, but the value is not provided if another field changed. Since true !== undefined !== false, a warning was raised.
Solution:
Only fire check the constraint if to_check is in the values.
closesodoo/odoo#33560
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
This merge applies various fixes to website_slides (eLearning).
Linked to task 1978530
closesodoo/odoo#33559
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Move code from website_forum allowing to edit its own profile. Otherwise
fields to update are not white listed. Also add an unpublished flag when
seeing unpublished users in order to know it if you have access to
depending on ACLs.
Linked to task 1978530
Related to PR #33559
This commit removes the uncategorized label from the course view. Note that
it only removes the label, not the content. FP request.
Linked to task 1978530
Related to PR #33559
This commit fixes the Review tab on the course page. The tab shows up even
if the channel does not allow comment. This commits fixes that behavior.
Linked to task 1978530
Related to PR #33559
Before this commit, the object used by Optimize SEO 'wizard' was always the
main object, without any possibility to change that (except by changing the
main object but that would cause a lot of other issue, eg edit in backend).
This commit add the possibility to explicitly set a seo object on the html data
attribute.
If set, this one will be used instead of the main object.
This is useful for event.event where all the event pages (with website menu
enabled) would share the same SEO since the main object would be the
event.event.
With this commit, the seo object is now the website.page, thus giving the
possibility to have a separate SEO for every event pages.
(Required for Odoo.com website for OXP)
closesodoo/odoo#33194
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
left join lateral is the postgresql optimized way to use parameters in
sub queries.
closesodoo/odoo#33526
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
If a non website_published user was 2nd in karma position, the all users page was
displaying in the top 3 a user with position 4 (in rank) as "normal users" cannot see
non published users.
The field karma_position is now deprecated and will be removed in master.
Task ID : 2000687
PR #33475
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, mail status manager was regularly fetching
`im_status` of partners with `this._rpc()`. This used the main
thread worker, so it may be overloaded because of that.
To mitigate this issue, mail status manager now uses a new route
`/longpolling/im_status` to fetch `im_status` of partners using
the longpolling thread worker.
closesodoo/odoo#33238
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this commit, the `author_id` of a message with odoobot was
`"ODOOBOT"`. This leads to some issues due to `author_id` being
considered as an array `[partnerID, name]`.
Because of this, mail status manager was registering a partner with
ID `"O"` (1st char of `"ODOOBOT"`) for fetching its `im_status`. Its
`im_status` was never updated, since no partner has such ID. However,
the mail status manager kept this partner flagged with missing
`im_status` and still attempted to fetch its `im_status`,
indefinitely.
This commit fixes the issue by turning `author_id` of a message with
odoobot into arrray `["ODOOBOT", "ODOOBOT"]`. That way, `author_id`
of a message is always an array, and the `im_status` of `"ODOOBOT"`
is no longer fetched.
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>
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>
Before this commit, Odoo notifies the user of all the recurring past
events, existing before the installation of the module Calendar (old
events imported when synchronizing with Google, for instance). This
occurs only the first time a synchronization with Google is made. This
occurs because Odoo notify all the events that occurs since the last
time it notified, and the first time you install the module the date of
the last notification is empty.
Now, when the module Calendar is installed, the date of the last
notification is set by default to the current date (the date of the
installation of the module)
opw-1942443
closesodoo/odoo#32535
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>