A tour tooltip was targeting a snippet which is at the bottom of the
page, we now target a snippet which is on top of the list so that the
related tour tooltip is more visible.
task-1942742
closesodoo/odoo#31400
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In the Project Overview, the Profitability report takes into account
Timesheet costs, but doesn't include information on Revenue.
Because of that, the user is missing crucial information to determine
the profitability of a given project.
This commit aims at fixing this issue by sending the user to the
'Project Costs and Revenues' report of the concerned project when
clicking the 'Profitability' button within the Project Overview page.
Task-1963932
closesodoo/odoo#32554
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This removes the 'V' box and it now validates the entered value when the
user clicks outside the box.
task-1952964
closesodoo/odoo#32291
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the back button was a small button top right.
But in other modules, the back button is a full width button, like on /my/order
This commit adapt the back button to have the same style by using the adequate
template.
To do so properly, the `o_portal_fullwidth_alert` div was moved from
`portal.portal_layout` to `portal.frontend_layout`.
That way, templates calling `website.layout` can also use it as it inherits
from `portal.frontend_layout`.
task-1943427
closesodoo/odoo#31387
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Mitali Patel <mpa@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Before this commit, the back button was a small button top right.
But in other modules, the back button is a full width button, like on /my/order
This commit adapt the back button to have the same style by using the adequate
template.
To do so properly, the `o_portal_fullwidth_alert` div was moved from
`portal.portal_layout` to `portal.frontend_layout`.
That way, templates calling `website.layout` can also use it as it inherits
from `portal.frontend_layout`.
task-1943427
closesodoo/odoo#31387
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Mitali Patel <mpa@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Set the same icon and title for stock move line buttons and change the
action of the sml button in MRP Unbuild to open stock.move.line model
instead of stock.move model.
Task #1966567closesodoo/odoo#32570
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
1. In the systray messaging menu, when hovering on a notification
linked to a document chat, it now shows an "expand" icon. Clicking
on icon opens the corresponding form view with the chatter.
2. Messages in a document chat window no longer show linked document
in their header, as this is redundant with title of chat window.
3. Font size of words "on" and "from" in header of message in chat
windows have been reduced in order to closely match font size of
document link.
Task-ID 1929169
closesodoo/odoo#30957
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently the assumption is that if email field doesn't exist on the target
model the mail field has to be email_from. So if one model is targeted and
does not have a field email nor email_from the seen list will raise as it is
searching at least on email_from on the targeted model table.
Better heuristics implemented here is to apply the same rule as
'get email field' from MailThread.message_get_default_recipients§). It
searches for email_normalized (address mixin), email_from, partner_email
and email fields in addition to partner_id which covers all use cases in odoo.
Related to task ID 1907292
Linked to PR #28535
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to have more information available in list and form views. As
trying to access those models is a technical move let us give users all
necessary information to understand / debug a bit what happens.
Concerning links we add necessary view type and fields to ease understanding
of tracking data. Notably in mass mailing mailing related information is added
for clicks.
This commit is linked to task ID 1924711 and PR #30059.
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some tests had to be adapted because they relied on the buggy behavior:
this was particularly the case when they tried to write on readonly
related fields.
closesodoo/odoo#32460
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, the field assignment would cache the value it received, even
if that value was altered during `write`. This can happen if `write` is
overridden (for example to resize images), or it could also happen if a database
procedure is altering the value.
To fix this issue, we do not cache the value that was assigned. This implies
that additional queries may be necessary to retrieve the value, but those were
already necessary most of the time, so it does not have a significant impact on
performances.
On a chat window on mobile, the keyboard can be closed by clicking in
the conversation, then there's no way to send your message.
This commit add a "send" icon in the input, after emoji and attachments
icon. Actually the button was already present on mobile but hidden
because of the class o_composer_button_send (used for multiple "send"
buttons). This is fixed by restricting the hidding only to the desired
button.
It also removes an unused 1px top/bottom margin on the thread composer
(wasn't visible as the buttons' background color is the same as their
parent's background).
Finally applying the brand-primary text color on the "send" button only
when not being in a "mini composer" mode instead of globally.
Task ID: 1943863
closesodoo/odoo#32568
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Rev. odoo/odoo@9fbb4fb wrongly removed the fixed width on handle and
button width on list views.
This commit restores it.
closesodoo/odoo#32467
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since rev. odoo/odoo@015958d it is possible to add buttons in list group
headers. These buttons are defined in <groupby> nodes, pointing to m2o
fields. Modifiers specified on these buttons thus use fields on the m2o
comodel.
There was a traceback in editable list view, when grouping by a m2o
that defines a groupby button with modifiers as the modifiers are not
registered with the same datapoint. When updating the modifiers, one
must ensure that the modifier are related to the updated record.
closesodoo/odoo#32456
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Task#1964518
This commit removes es6 code that was unintentionaly introduced
by the product configurator for better compatibility
closesodoo/odoo#32452
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Usecase:
- Go on a BoM with a routing. Go on the first operation and set
the next operation(batch field) as 'Once a minimum number of products is
processed'.
- Set the batch size (minimum operation) to 0.
- Create a MO and plan it.
- The second work order has state 'pending' instead of 'ready'
It happens because the system automatically set the first wo as
'ready' and the following as 'pending' and don't check the batch
and batch_size.
closesodoo/odoo#32628
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The validation error introduced in 552da8dc can pop up in contexts where
it is not expected;
e.g. not in editing user rights but while upgrading a module.
Therefore we make it more explicit, giving the user a way to resolve the error.
closesodoo/odoo#32623
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
From an onchange, at this point, (4) doesn't mean "no change" it means
"reset to database values". Through the interplay of client and server
reverse-engineering one another at this point the client (is supposed
to) assume the o2m results are "complete" and a diff from the
current *in-database* values rather than the in-client (sent to the
server) ones.
So a (1) should completely replace all existing values, and a (4)
should just remove all of them (but keep the record linked).
closesodoo/odoo#32617
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Create a sale.coupon.program with a discount of 10% and generate coupons for it
- Go on the shop and add a product of 100€ in the cart
- Go in your shopping cart and add a promotion code
- A new line has been created in your cart with a discount of 10€
- Click on "Process to checkout"
Bug:
The discount had been removed from the cart
Technically:
When clicking on button "Process to checkout", the function "recompute_coupon_lines" is called several times.
The second time, in function "_remove_invalid_reward_lines", the valid applied coupon program couldn't be retrieved
due to the sale price of the discount_line_product_id = -1000000 €. The function _filter_on_mimimum_amount filtered
the targted program because the untaxed_amount of the order was equal to -999900€. So the program._compute_program_amount
was all the time greater than untaxed_amount or untaxed_amount + tax_amount
It s not consistant to set a default value to -1000000 to prevent pricelist strikethrough because in some currencies,-1000000 is not enough.
Now the reward lines are not strikethrough.
X-port/cherry-pick of odoo/enterprise@2748249c0b
opw:1957671
Task#1958723
This commit fixes the survey form to allow creating, testing and sharing
surveys that don't have sections as long as they don't use the "page_per_section"
layout.
closesodoo/odoo#32159
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- when answer is correct, then score should be +1.
Related to Issue: 1967506
closesodoo/odoo#32612
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Steps to reproduce the bug:
- Create a SO with no salesperson
- Add a SO line with 2 storable product
- Confirm the SO and deliver only one product
- Click on "No backorder"
Bug:
A error was raised because the function "_log_activity"(called by _log_less_quantities_than_expected) requires a responsible
Partial Backport: https://github.com/odoo/odoo/commit/e1f9499d2672fb0a346f8ac74552f038f5204a64
opw:1950968
closesodoo/odoo#32592
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Set a product P to average valuation, real time
- Create a PO for 1 unit @ 100, validate the picking
- Create a PO for 1 unit @ 0 (e.g. you receive a free product)
You cannot validate the picking because of the message 'The cost of P is
currently equal to 0...'
This error message is historical, to prevent users from an incorrect
configuration.
Since we still want to prevent misconfiguration, but support the
mentioned use case, we introduce an `ir._config_parameter` for people
who 'know what they are doing'.
opw-1962249
closesodoo/odoo#32550
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This reverts commit abc45b1
Since by default the ondelete attribute of a many2one is `set null`,
this was completely unnecessary to begin with.
Bug caused by this commit:
Unlink a record that has some attachments.
The unlink first removes the record, then its related attachments.
It calls remove_as_main_attachment, which reads the attachment res_model and
res_id. This triggers a check that the related record can be read.
However the related record has already been removed, an exception is raised.
It is thus impossible to unlink a record.
Closes#32563closesodoo/odoo#32572
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In multicurrency
Do an invoice with cash basis lines in the foreign currency
Make a payment for almost all the invoice
"almost" refers to the point where virtually all taxes will be paid
i.e., paying 90 over 100, that contains a tax of 5%
The tax paid will be an amount almost equal (to a few cents) to the
total amount of the tax
It is not negligible, but if the currency rates are in the right configuration
(i.e. 0.005888)
Before this commit: the Cash Basis reconciliation will be considered as full and will trigger
the creation of the Exchange Diff Entry.
In turn, paying the rest of the invoice will pop up an error saying that some entries are already reconciled
(with the Exchange Diff entry)
It is not *that* that an exchange rate entry has been created the first time
after all, a percentage sufficiently close to 100 has been paid
But it blocks subsequent reconciliation, hence this fix
After this commit, if the cash basis entry doesn't match at least 100% of the paid move
then, we force to not check for full reconciliation
OPW 1953027
closes#31168closesodoo/odoo#32023
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, test reconciliation was inherited by
test reconciliation widget.
It made the actual test_xx functions of the former
being executed twice
After this commit, we create an intermediary test class for setUp and helpers
And the tests for each class execute only once
Before this commit, when reverting a move
that will be subjected to the creation of a cash basis move
the process failed saying that some entries were already reconciled
That was because the process tried to create the cash basis move during
the revert.
This is wrong, because no real cash is dealt with.
After this fix, the move lines of the original entry are reconciled
only with their revert counterpart
OPW 1938809
closes#30972
Priyanka Kakadiya