In task-2355704 changes were made to the pdf layout designer to allow more
flexibility when setting company data. However, for the default values of both
company_details and report_footer, the data wasn't being escaped, therefore
offering security risks. Also, they didn't take into account the address_format
when computing the default value. This PR implements Markup usage in the html
fields and fixes _default_company_details to use the set address_format.
closesodoo/odoo#78725
X-original-commit: 83aeb8fbc3b2a4b39123f756232e34c1ce603299
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Updating menuitem names to avoid mismatches between the menuitem and the
action title.
TaskId-2664863
closesodoo/odoo#78148
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To avoid mixing both plan and planning in hr plan options it was decided
to reword menus to plan instead of planning.
TaskId-2664863
Part-of: odoo/odoo#78148
Ensure that all models have their own explicit definition of identifying
fields. Prior to this commit, if a model did not have identifying fields,
the ones in mail.model were used implicitly because of the inheritance.
closesodoo/odoo#78722
X-original-commit: 02fb0c7caaa8a9813e7e78b464710eb772091e44
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When visiting a page with enable_editor set to true, the web editor
will be automatically started. However, while the editor is loading,
the end user can still click other buttons in the navbar.
For example, some changes in the web editor require a save and reload
of the current page being edited. After saving, the same page will be
reloaded with enable_editor.
This commit blocks any clicks while the editor is being loaded.
task-2607755
closesodoo/odoo#78721
X-original-commit: 89bdfcd16828e1432900ea46118fd6ddadf96f2d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Sets the `inventory_quantity_set` as an editable field (not readonly)
and creates its own compute to avoid to override it each time the
`inventory_quantity` is modify and we set the `inventory_quantity_set`
aside (before this commit, this field new value was always overrided by
the `inventory_diff_quantity` compute).
This is useful when we want to write on the quants from the Barcode App
as we can write on `inventory_quantity` and `inventory_quantity_set` at
the same time.
task-2632818
closesodoo/odoo#78719
X-original-commit: 489e76ade600f7983a9a1976c04529ac542fdd44
Related: odoo/enterprise#21810
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Description of the issue/feature this PR addresses:
When using analytical account and invoicing a fixed price sales order
item, which is linked to a project task, where timesheet has been
recorded, the invoice gets double counted into the project revenues -
both as Invoiced and as Other revenues on the project overview
profitability.
Current behavior before PR:
The invoice gets double counted into the project revenues - both as
Invoiced and as Other revenues on the project overview profitability.
Desired behavior after PR is merged:
The invoice gets counted only in the project revenues as invoiced/to
invoice on the project overview profitability.
This commit adds tests to assess this use case is covered.
PR : #78230
opw-2631163
closesodoo/odoo#78646
X-original-commit: ddab279813a71caa2fa7ea081e9cbf0c56ae3613
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Thibault Libioulle <tle@odoo.com>
This commit fixes multiple issues in project profitability report.
Steps to reproduce opw-2596224:
- Go to sale
- Make a RFQ for a service product with service_policy set at
delivered_timesheet (Timesheets on tasks), set quantity as 10
- Confirm order and create two invoices for 15%, confirm the two
invoices
- Create a credit note for one of the invoice and confirm it
- Go back to the Sale Order and click on Project Overview
=> Inconsistencies (Downpayment reported twice)
- Add an expense
=> Inconsistencies in expense amount untaxed invoiced
- Add timesheets
- Create an invoice from the SOL
=> Inconsistencies in Other costs, counting the downpayment.
This issue is fixed by :
- Excluding downpayments which are linked to a reversed invoice line
- Use expense amount to invoice and expense amount invoiced separetely
in the project overview.
- Do not report not invoiced SOLs in the expense amount invoiced.
- Exclude negative amounts in analytic account which are linked to
credit notes.
- Include all services and not timesheetes SOLs linked to project,
project task or project's analytic account in the invoice/invoiced
subquery.
- Remove the unused downpayment column in the subqueries
- Remove unused subquery (relative to downpayment)
PR : #78230
opw-2596224
opw-2631163
X-original-commit: 69c5a55887d67b8852c7c45a52def38f3c742e7d
Part-of: odoo/odoo#78646
Before this commit selecting a class-based color (gray scale,
o-color-1~5) was ignored when configuring a custom button colors.
After this commit the color's class is applied.
Additionally, upon switching between Custom and other types, the custom
UI is now cleaned up.
task-2653874
closesodoo/odoo#78720
X-original-commit: 26d37812f0217ae913c8ddf761bcb26b5c44bff5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit if button text had styles, they would override the
color set by customizing the button.
After this commit button text styles are removed when applying custom
button colors.
task-2653874
X-original-commit: 03c02639f1e92b58a38d8efb620b17761ae2d81d
Part-of: odoo/odoo#78720
This isn't a problem in production, because the ActionContainer is
never destroyed, but it caused a small memory leak in the test
environment.
closesodoo/odoo#78698
X-original-commit: d01c89d80d58763e45309dbcfbf83f852866982e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the ui service listened to the "change" event
on several MediaQueryList corresponding to specific window sizes.
However, those event handlers were never removed. Whereas this
isn't an issue in production (services are started once and live
forever), this caused a memory leak in tests, where services are
deployed on demand, test by test.
There is no cleanup function for services (since they live forever
by nature). In the test environment, we have a solution for handlers
bound on window (i.e. window.addEventListener), by monkey patching
the function (thanks to the browser object), and automatically
removing all handlers bound during a test, at the end of that test.
This commit fixes the memory leak by no longer using addEventListener
on MediaQueryList (as this is a deprecated feature anyway [1]), and
simply using window (or browser)'s addEventListener instead. This
leak sometimes produced a timeout in the QUnit test suite [2].
[1] https://developer.mozilla.org/en-US/docs/Web/API/MediaQueryList/addListener
[2] https://runbot.odoo.com/web#id=2374&action=573&model=runbot.build.error&view_type=form&cids=1&menu_id=405
X-original-commit: d86cc5c016cf4eff9a7e4f8b35a9ed38ddc24636
Part-of: odoo/odoo#78698
Before this commit, those tests sometimes failed because we didn't
correctly wait for the load and reload promises.
X-original-commit: f62503a56c4ec5c3de6638c5fe2138330d217eac
Part-of: odoo/odoo#78698
This commit *could* prevent a test from failing randomly. The
important part in the diff is the switch from $.Deferred to native
Promise. JQuery Deferred behave differently upon resolution (it is
sync if the deferred is resolved directly, whereas it is not the
case for native Promise). I couldn't find any other reason to
explain why the test was sometimes failing. There is no reason to
use Deferred anyway.
The issue didn't occur after this commit in more than 600 builds.
[1] https://runbot.odoo.com/web#id=2297&action=573&model=runbot.build.error&view_type=form&cids=1&menu_id=405
X-original-commit: ed0761dce44bd37cdd9d40ddd6e021517f466f97
Part-of: odoo/odoo#78698
Before this commit, the changed test sometimes failed on runbot
(rarely though), because it might happen that the debounce released
before the promise returned by the click helper resolved (e.g. if
the server was overloaded, or was garbage collecting...). That
promise waited for a setTimeout, and then for a nextAnimationFrame.
In this scenario, there's no need to wait so long, as there is no
rendering to wait for.
Example of failing build: https://runbot.odoo.com/runbot/build/10360554
X-original-commit: 880c4683698c987f212e4a113b374230566001f1
Part-of: odoo/odoo#78698
Before this commit, it wasn't possible to patch some functions
(e.g. setTimeout) on window, because of the way we call them.
Indeed, we typically do `setTimeout(...)`, because this function
doesn't need to be bound to the window object.
X-original-commit: 476dbf75bb88dc2ddfdd47c1f229ce53cf7fadb7
Part-of: odoo/odoo#78698
In some cases when creating a new ticket, the default product
type shown is a "Consumable". It should rather be handled as a
"Service". In later versions, a detailed type is created, but the
base product type should be set to service too.
This commit uses the `product_id` `context` to set the default
detailed type to "event".
Task-2655226
closesodoo/odoo#78690
X-original-commit: a03e12810152559efc712cb067756d517c7647ca
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, DDT use the product_uom_quantity of product for the ddt move which is inaccurate in case of no-backorder change in quantity
The fix correctly check if the done quantity is other than 0 for the delivery and if it is, use it as the delivery quantity
opw-2663174
closesodoo/odoo#78671
X-original-commit: 8678bf385d79adf207c12beb47012898dbb4ddc9
Signed-off-by: Florian D <fdamhaut@users.noreply.github.com>
In the new web client architecture, the user context is added to server
requests through the ORM service and is therefore not needed in the
action context. Thus the commit 7354d16 has removed it from the action.
Before the new webclient architecture, the user context was always
prepended to the action context. So this commit reintroduces it for
the legacy views and client actions through their proper adapters.
closesodoo/odoo#78685
X-original-commit: 7975674166a3d8fa9cd8714adab769a7fd681368
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
Before this commit
The current action is stored in the session storage with its evaluated
context. This design is wrong because a context is by definition
contextual which means it has to be evaluated at the last possible
moment to ensure it reflects the most recent context.
After this commit
The current action is now stored in the session storage it its most
original state. This is sufficient as in any case actions go through
the doAction method which evaluates the context right before applying
the action logic.
X-original-commit: 2533d47a1d312907389fb85af83f8812c402a609
Part-of: odoo/odoo#78685
Bug
===
If we open a view in readonly mode, click on a radio widget and if a
constraint exists on this field, an error message is raised.
(e.g. the enroll field in "website_slides_sale").
Technical
=========
This is because in the "Basic controller", in the "_onFieldChanged",
we force "force_save" if the view is in readonly mode. This is wanted
for widgets that can change the value even in readonly mode
(e.g. Priority), but clicking on a Radio widget switch the mode to edit,
so this is not needed.
To fix that, we call `setValue` after switching to the edit mode. So
the `setValue` is skipped in `_onInputClick` if we are in readonly mode,
and the `setValue` is done in `_quickEdit` instead.
Task-2668763
closesodoo/odoo#78684
X-original-commit: ff1329ca86691dd5f042158de6913c4aa2c69b6c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, The 'TestWebsiteCrm.test_catch_logged_partner_info_tour' is randomly
failing on runbot. The tour is triggered on contactus page. Tour bug is
occurring because editor may not be completely loaded. In that case some
selectors are not accessible.
This tour is linked with selectors. In this commit updates the selectors and
add the extra triggers in order to be sure editor is fully loaded and the
tour can resume.
Task-2649723
closesodoo/odoo#78676
X-original-commit: d135916b754ae7fde184c4e2d69177dbc1dddc9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Go to purchase > Configuration > Vendor Pricelists
- Filters > select the “Active” filter
Problem:
Currently, the filter does not include records that do not have a specified `”date_end”`, even though they are considered active.
Opw-2659829
closesodoo/odoo#78643
X-original-commit: bb8bef5cff3b67e42218469e898f2b95e4ab315d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
When invoicing a product with multiple variants and with anglo_saxon_accounting, the COGS would be the wrong amount.
The function _stock_account_get_anglo_saxon_price_unit() was selecting the first BOM among all variant BOMs.
Using the variant_bom_ids when existing prevent this situation.
OPW-2662863
closesodoo/odoo#78654
X-original-commit: c07d005ae8153745c67527bbf97749e6473e4d41
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: DavidFesquet <DavidFesquet@users.noreply.github.com>
This is a followup on b6c688caa2, which
has introduced a new bug.
Consider two groups A and B in a given category, where B implies A and
also A.id > B.id. For the sake of simplicity, assume that A.id=2 and
B.id=1. Following the commit above, the name of the group selection
field will be 'sel_groups_1_2'.
Consider a user in group B. Because B implies A, this means that the
user now belongs to both A and B. A call to read() on that user returns
field 'sel_groups_1_2' with value 2, which on the form view appears as
the user belonging to A only.
The error is in read(), which assumes that the group ids in the field
name correspond to the implication order of the groups, which is no
longer the case since b6c688caa2.
closesodoo/odoo#78662
X-original-commit: e73c406671a51e9c1c4872a9e85eebe5656ea38e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
On the right panel of the mail editor, the icons of the mass mailing
module do not match with the other icons. We will then update them to
improve the consistency of the layout. The icons will now have the same
background color as the other icons.
task-2658133
Co-Authored-By Carlos Valverde <cvs@odoo.com>
closesodoo/odoo#78645
X-original-commit: 8aa5c39c0ba84a4e5bdb27ff6d70a43ad90ae4af
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Before this commit, it was possible to edit scroll buttons with the
editor toolbar.
task-2656662
closesodoo/odoo#78637
X-original-commit: ca5a36323900a27896761ed12c002d22b6c6cf53
Related: odoo/design-themes#523
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
Add more fields when we merge multiple leads to be sure not to lose
valuable information.
Specifications
==============
New fields merged
-----------------
Those fields are now propagated to the destination,
- referred
- color
- recurring_revenue
- recurring_plan
- function
- lang_id
- date_deadline
- reveal_id
- lead_mining_request_id
- reveal_ip
- reveal_iap_credits
- reveal_rule_id
- event_lead_rule_id
- event_id
- lost_reason (if the destination lead is lost)
- iap_enrich_done
- tag_ids
The address is taken from the lead with the most non-empty address
fields (sorted by highest rank if multiple leads have the same amount
of non-empty fields).
Followers
---------
When merging multiple leads, we want to move the followers to the
destination lead if they posted a message in the last 30 days.
A message will be added in the merge note to know which followers have
been added.
Views
-----
Remove the "groups" attribute on the recurring revenue
fields. Instead we hide them directly in the views.
Task-2447721
closesodoo/odoo#75742
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Purpose
=======
When merging multiple leads, we want to move the followers to the
destination lead if they posted a message in the last 30 days.
A message will be added in the merge note to know which followers have
been added.
Task-2447721
PR odoo/odoo#75742
Purpose
=======
Add more fields when we merge multiple leads to be sure not lose
valuable information.
Specifications
==============
Those fields are propagated to the destination if the value on the
destination is Falsy
- referred
- color
- recurring_revenue
- recurring_plan
- function
- lang_id
- date_deadline
- reveal_id
- lead_mining_request_id
- reveal_ip
- reveal_iap_credits
- reveal_rule_id
- event_lead_rule_id
- event_id
The "lost_reason" field is propagated to the destination only if it's
lost (otherwise, it makes no sense to have a lost reason on a non-lost
lead).
The field "iap_enrich_done" is set to True if at least one lead has been
enriched.
We also keep the sum of all the lead tags (and remove any potential
duplicates).
The address is taken from the lead with the most non-empty address
fields (sorted by highest rank if multiple lead have the same amount
of non-empty fields).
Task-2447721
PR odoo/odoo#75742
Purpose
=======
This commit remove the "groups" attribute on the recurring revenue
fields. Instead we hide them directly in the views. This group was used
only to turn on / off the feature, not for security reason. So it's
fine to move the group in the views.
It will help for the lead merge so we will not be forced to use SUDO
during the merge.
Task-2447721
PR odoo/odoo#75742
PURPOSE
Light Usability improvements for Reseller module.
SPECIFICATIONS
- Adding some demo data for the menu items Partner Level and Activations to
make sure that user's aren't completely stuck until they find the menu items.
-> Partner Level : Bronze, Silver, Gold
-> Partner Activations : First Contact, Ramp-up, Fully Operational
- Adding action helper for menu items Partner Level and Partner Activations.
-> Partner Level :
Create a Partner Level
Partner Levels allow you to rank up your Partners based on their
performances.
-> Partner Activations :
Create a Partner Activation
Those are used to know where your Partners stand in your onboarding
process.
- Changing name of the menu item "Partner Level" to "Partner Levels".
- Changing Partner Levels and Activation in res.partner form selection to
standard many2one.
- In the partner form changing the location of geolocation to below the groups.
- In kanban view displaying the record to which the partner is assigned, if
there is no assigned partners it will show nothing.
- Change the "Title" label to "Opportunity" in portal, because people think it's
a title as "Doctor" or "Mister".
- In portal while creating new Opportunity the "Opportunity" field will
auto-filled as "contact name's opportunity" when contact name is entered.
- The "opportunities" stat button (res.partner) will show opportunities where
the partner is either customer or assignated partner.
- From crm.lead form letting users to create new Assigned Partner on the fly.
But since the domain requires some basic configs, a new partner won't appear
in the next searches to prevent this, when a new partner is created through
here, we will add it the lowest activation and level possible.
LINKS
PR #67524
Task 2443894
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
- Right now, if you click on 'Geolocate' button on partner form view, and if
partner has no address, it gives no feedback and user doesn't know what
happend.
With this commit, if the geolocating does not work, user will get a toast
notification telling him that 'No address found' to avoid confusion.
- When we click on 'Automatic Assignment' button from crm form view,
if there is no country set on lead, odoo skips the process, but we get the tag
that 'no partner available' which is not correct. It should be
there only when odoo actually tries to find the partner based on
lead's country.
This commit fixes the behavior by showing a toast notification to
user in this case, saying 'There is no country set in address'.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
Currently the 'Opportunities' stat button on partner form view does not show
the opportunities where current partner is assigned one, it only shows the
ones that have current partner(and it's children) set as a customer.
This commit includes such opportunities (where current partner is set as
assigned parter) in the count of stat button and on the view we get when
clicking this button.
taskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
This commit improves the following:
- Hides the icons under the 'Contact' section if the related
information is not available.
- Moves the 'Next Activity Date' next to 'Next Activity' on
opportunity edition dialog, and opens the date-picker to
schedule next activity below the input instead of above it.
- Increased the height of 'Details Next Activity' textarea so
that 'Next Activity Date' picker can be shown within the modal
without introducing scroll-bar.
- This commit renames the label 'Title' to 'Opportunity' to avoid
confusion, and auto-fills it based on the 'Contact Name' for the
modal that is used for creating opportunities from front-end.
Apart from that, this commit also improves string of the button
responsible to create new opportunity from front-end.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
This commit display the assigned parter on kanban view of opportunities next
to the partner (if assigned parter is set). For example, if the customer name
is 'Main Contact' and assigned partner's name is 'Assigned Contact', it will
appear in following format:
Main Contact → Assigned Contact
If there is no customer and only assignd parner, it will look like
→ Assigned Contact
Note that if there is only customer, or no assigned partner and no customer,
nothing changes in the view.
taskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- This commit removes `selection` widget given on 'Partner Level'
and 'Activation' fields on contact form view to allow users to
create records for them on the fly (with 'no_open' option).
- This commit moves geo-location related fields below the parter assignment
related fields in the 'Partner Assignment' page of contact form view.
- This commit adds default lowest 'Partner Level' and 'Activation' (based on
sequence) while creating assigned partner on the fly from opportunity form
view. The purpose is to allow user to select the created partner again in
'Assigned Partner' m2o, which displays only partners having 'Partner Level'
(grade_id) set.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- For sake of having basic config for 'Partner Level' and 'Activation'
in contact form view (until user discovers the dedicated menus under
CRM > Configuration > Resellers) in blank db, this commit moves the
demo data related to 'Partner Level' to data, and adds new data for
'Activation', in following sequence:
- Fully-Operation
- Ramp-up
- First Contact
Also, higher ranks for partner level and activation are considered
better, and so the tree views for them now display the records in
the order of their rank (highest on top).
Note that with this commit, we remove 'Platinum' partner level and
it's references that were available in demo data.
- Apart from that in this commit we have also done these changes,
- Renames the menu 'Partner Level' to 'Partner Levels' and adds
action helper for the same.
- Adds action helper for the 'Partner Activations' menu.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
Steps to follow
- Enable group_show_line_subtotals_tax_included
- Create a repair order and add a tax to a line
-> The subtotal doesn't contain the tax amount
opw-2513287
closesodoo/odoo#78631
X-original-commit: 133888a1859d81a252177b58b046b54d22ba5ca8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
Before this commit
Each click event triggered inside a DropdownItem is default prevented
After this commit
Those click events will be default prevented only when the DropdownItem receives a props.href, which will turn it into an <a href/> element.
This corresponds to the initial intention: prevent the default click behavior of an <a href/> element and only keep the DropdownItem click behavior.
opw-2665795
closesodoo/odoo#78628
X-original-commit: 11760db91fc56fb8b998d77661f8d4d7842f3eb8
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Currently markup-ification of the legacy notifications system
display the html content in notification layout for some of the
notification of document and planning from commit: https://github.com/odoo/enterprise/commit/ba44461fea337ed2e5adbdfa1e8eede00b036def
So here in this commit, we make the method `makeLegacyNotificationService`
always `_.escape(message)` and pass `messageIsHtml: true` to the owl
notifications system so notification with html content will be displayed
properly.
Task-2657391
closesodoo/odoo#78627
X-original-commit: 7ce6d8d70be79c9c626865598b898dce9a18b045
Related: odoo/enterprise#21782
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Bug
===
If you send a URL (which will be transformed into a link tracker) to
an external website (e.g. in mass mailing, social, ...), the UTM values
will be added in the GET parameters of the URL.
The external website might crash if those parameters are not supported
by it.
We want to add a system parameter `link_tracker.no_external_tracking`
to be able to not add those UTM values in the redirected URL.
This is done only for external website, because it will never be an
issue if the URL redirect to Odoo.
Task-2657413
closesodoo/odoo#78616
X-original-commit: c8363b7bb74ace4e77b593efc3a9104143240141
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
New users automatically received the Leave Responsible role even though
they were not managing any employees.
closesodoo/odoo#78436
Taskid: 2635715
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Leonardo Pavan Rocha