Steps:
1. Create Employee A that related with user A / partner A in Sales
department
2. Create a channel Sales, set Auto Subscribe Departments as Sales
department
3. Archive Employee A / user A / partner A
4. Create a application B in Sales department and click button Create
Employee
5. An error occurred: duplicate key value violates unique constraint
"mail_channel_partner_partner_unique"
closesodoo/odoo#115184
X-original-commit: e5e2cc8e00d4aec6f76283e8c5a7e485d6e9ab63
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit introduces two small improvements to the autocomplete
component:
- the ability to autofocus the input, once it is mounted
- the ability to set an additional class to its root element
closesodoo/odoo#115142
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
With the special support for postmortem debugging removed, the
likelihood of needing / wanting the werkzeug remote debugger seems
even more remote (as it works in strictly less situations, only for
frontend non-json requests).
So remove that as well.
closesodoo/odoo#115176
X-original-commit: a2022783b652299155c460294c00dbced9b619ac
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It's done nothing since #78857 and it doesn't seem like anyone has
cared (found no issues or tickets).
Rather than restore the feature, just remove the leftover bits.
X-original-commit: 4a7cfc8844eb9b754f16f9d013452d5bde8770b5
Part-of: odoo/odoo#115176
Add a new edi_format "SG BIS Billing 3.0" available for SG companies.
This format is based on BIS Billing 3.0.
task-3180983
closesodoo/odoo#115147
Signed-off-by: Laurent Smet <las@odoo.com>
The purpose of this commit is to convert the client actions
'action_get_drive_certificate' and 'action_post_sign_invoice' to the new
architecture.
closesodoo/odoo#111507
Taskid: 3164406
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit
------------------
Before this commit, the db migration from the 15.0 to 16.0 test case is failing
while this is migrating analytic_account, in computing methods
trying to use a direct field without reference.
Traceback (most recent call last):
File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 223, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 405, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 2977, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3126, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5847, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1188, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1347, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4186, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/16.0/addons/account/models/account_analytic_account.py", line 38, in _compute_invoice_count
self._cr.execute(query_string, query_param)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 516, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 313, in execute
res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "move_id" is ambiguous
LINE 1: ...lytic_distribution) as account_id, COUNT(DISTINCT(move_id)) ...
After this commit
-----------------
In this commit added the reference to the move_id which is used without reference.
closesodoo/odoo#115160
Taskid: 3141476
X-original-commit: 6ae96c7f707cdd2beac241280957bd3b3661b94d
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit: in the PoS restaurant paid orders' date will be shown
wrong. The problem is that it will be sent based on the user's timezone,
and `init_from_json` in PoS restaurant converts it again to the local time.
The solution is to send the time with its offset. Converting the time to
string will keeo the time offset in the format.
opw-3195027
closesodoo/odoo#115128
X-original-commit: 882dab5fdba32bb51ac4efbc3f0d4e684203a622
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
To reproduce the issue:
1. Create user with no access rights apart from user rights in Sales,
Sign, Project and Timesheet
2. Create a project, add a task inside and link an analytic account
to the project
3. Create an RFQ, add a product linked to the analytic account
4. Confirm order, receive product, validate, create bill
5. Log in with user
6. Try to access the analytic account through:
Project->Task->project name->Settings->Analytic account
7. An error message pops-up "You are not allowed to access Purchase
Order (purchase.order) records."
Error: You should be able to access the analytic account, but the
Purchase Order smart button should not be visible/present
The data access by the smart button was not stopped by rules or
groups, thus data was always trying to be loaded, even when the user
did not have the access rights
OPW-3180788
closesodoo/odoo#115058
X-original-commit: 9e8b2ba1ae05de72f492d833edd8da91ded6f5b0
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
Current behavior:
When you make a purchase that should be rounded down, for example 1.97
rounded down to 1.95. On the payment screen if you select a payment
method and pay with a greater amount than the base amount. The total due
would be rounded incorrectly to 2.00 instead of 1.95.
Steps to reproduce:
- Create a product with a price of 1.97
- Set a rouding down method of 0.05
- Open a pos session
- Add the product to the order
- Select a payment method, for example cash and enter an amount greater
than the base amount, for example 5.00
- The total due will be 2.00 instead of 1.95
opw-3175726
closesodoo/odoo#114427
X-original-commit: 45994a5f8b3f87c46e39c260183663023d51e080
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When stacking a bar chart, you often want to see the resulting sum of the
different groups (esp. if there are negative values). For example, when
displaying a stacked chart of invoices vs credit notes, you usually also
want to know the net total.
This is done only on stacked bar charts that have single column per
x-axis label and with more than one level of groupby.
closesodoo/odoo#114132
Task-id: 3193260
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
It's currently impossible to set fixed delivery costs in eCommerce without installing Inventory. This is a problem for one-app free instances on our SaaS, which would need to pay for a feature that should be part of the basic eCommerce features bundle.
Delivery is now split from inventory/stock module to allow for a soft free integration into website_sale. This PR makes it possible to define fixed-cost delivery methods in eCommerce without installing Inventory by adding a direct dependency of `website_sale` on `delivery`. The bridge between those two modules is therefore included in the former.
Steps are:
- extract the Inventory logic from the `delivery` module into a new `stock_delivery` module;
- move `website_sale_delivery` into `website_sale`;
- adapt dependencies to `delivery` and `website_sale_delivery`;
- remove bridge module with loyalty directly in `website_sale_loyalty`;
- move `website_sale_delivery_mondialrelay` to `website_sale_mondialrelay`.
task-3074497
task-3203210
See also:
- https://github.com/odoo/enterprise/pull/36609
- https://github.com/odoo/upgrade/pull/4362closesodoo/odoo#110686
Related: odoo/upgrade#4362
Related: odoo/enterprise#36609
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In ecommerce, the form vue of shipping methods should be improved to
easily set up fixed delivery costs. This commit improves the
user-experience and solves bugs on the fields displayed.
task-3203210
Part-of: odoo/odoo#110686
It's currently impossible to set fixed delivery costs in eCommerce
without installing Inventory. This is a problem for one-app free
instances on our SaaS, which would need to pay for a feature that
should be part of the basic eCommerce features bundle.
This commit makes it possible to define fixed-cost delivery methods in
eCommerce without installing Inventory by adding a direct dependency of
`website_sale` on `delivery`. The bridge between those two modules is
therefore included in the former.
Part-of: odoo/odoo#110686
Extract the Inventory logic from the `delivery` module into a new
`stock_delivery` module. This will allow to integrate the basic delivery
features into the website_sale app in a one-app free database.
task-3074497
Part-of: odoo/odoo#110686
Before this commit, it was not possible to install hr_expense alone.
This commit enable the installation of standalone hr_expense by adding
missing dependency.
closesodoo/odoo#115140
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
To reproduce
============
- on Time off, create a time off with a big description
- approve this time off
the form breaks
Problem
=======
the style of text overflow is not handled
Solution
========
add `text-break` class to the input part
opw-3118856
closesodoo/odoo#115120
X-original-commit: 10bdfc46f32458f9f8a8fe5f9d298bfc10591aea
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
The test added in dea66e1df317ca8782a68ece6c1e5917f6e8f3ec depends on a `mail`
helper, even though it is in the `web` module.
opw-3133731
closesodoo/odoo#115104
X-original-commit: e0ac9c41c6852cc147a9dea236421193161d7abe
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Chrome 111 enabled checking of websocket origin: if the WS connection
sends an Origin head which is not whitelisted with the new
`--remote-allow-origins` switch it is rejected.
Turns out websocket-client (amongst others) *does* send an `Origin`,
which trips the check, and means tours immediately break when trying
to run them as Odoo's test harness is unable to connect to (and
control) the devtools.
Suppress sending `Origin` to fix the issue.
To make the watch mode work, set `--remote-allow-origins`: since we
specifically only bind the devtools to the loopback
address (127.0.0.1) whatever issues this plugs are unlikely to affect
us. We might eventually want to change the behaviour of the watch
feature for UX reasons and remove this in the future though, either by
working through the non-ws remote inspection (`chrome://inspect`) or
by having the `watch` mode run in a normal browser directly instead of
having a browser connect to a headless browser.
Chrome 111 changeset: https://chromiumdash.appspot.com/commit/0154caeefc74530d5cb57ce71608beb1b77bca39
Chrome tracker issue: https://crbug.com/1422444closesodoo/odoo#115067
X-original-commit: 47a02b3924c3e4d1690e336fdd764383393ee378
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
before this commit, enabling the mass editing for the
various tree view using the studio throws exception
saying field used in domain is missing in the view
* install studio, hr, hr_holidays
* open department tree
* enable mass editing for the tree using studio app
* exception will be raised
similarly for the hr.job, hr.plan, hr.work.location and hr.leave tree views.
after this commit, on enabling mass editing on this tree view, exception will not be shown.
closesodoo/odoo#114935
X-original-commit: 70ece4c85c076962b8ebeed2a248d5228c5f8d0a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
1. Install DIN 5008
2.1. Settings
- [Companies] > [Document Layout] > Configure (..)
- Set [Layout] to DIN 5008 and paper format to one with DIN 5008
- write on [Company Tagline]
- [Download PDF Preview]
2.2. Accounting
- Customer Invoices
- click an invoice and [PREVIEW]
Before: Slogan not added
After: Added
versions: up to master
opw-3145751
closesodoo/odoo#115125
X-original-commit: 9d6876dbcb82b18d30fa8811456d26f67586344d
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Prior to this commit, the event handlers that prevents the default
behaviors of a click was bound onto the $editable after the wysiwyg
editor had started.
This meant that during a very short period, the element could have the
"editor_enable" class but would not prevent clicks on the document
from triggering a default behavior.
This issue is not as important in versions prior to 16.0, because most
of the clicks on link would trigger navigation within the page,
canceling edit mode. If a traceback had appeared, it would be removed
quickly after, as the page was unloaded.
However, in 16.0, if the iframe leaves its current page, it can crash
the editor which now resides outside the page we are currently
editing.
Furthermore, the test introduced in [1] highlights the problem, as it
clicks on a link directly after checking if "editor_enable" is added to
the body within the iframe. This created a race condition, which means
the test crashed often.
This commit fixes the issue by using the click handler of the
website_preview to prevent the default behavior while in edit mode.
[1]: https://github.com/odoo/odoo/commit/050378dd8599b907ad429d4d1812602b557d0f73
runbot-18660
closesodoo/odoo#115119
X-original-commit: f9e51a8ab1cc469bd3dd4dba21856597d5e0f902
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Install Project, Timesheets.
- Create a new porject with allocated hours set to 40 hours (5 days).
- Taking into account that our company have a 8-hour/day work schedule
(40 hours/week).
- We go then to the timesheet app and we add a line for the project
created with 8 hours as hours spent.
- Now we got to the timesheet configuration and we change the uom to
days.
- We go back to the timesheet app and we see the result, we can also
try to add just 1 day.
Issue:
The days are not properly computed, only when we are in hours are being
computed properly. But when we change the uom to days, the computation
that we see in the list will still be wrong.
Solution:
We really take into account which uom are we working with so we
compute the time properly depending on the uom.
opw-3138053
closesodoo/odoo#115049
X-original-commit: a31a1b6aff4db0415dc9c44bae33901f4833aba1
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- select a different company from the main one
- under settings/discuss enable External Email Servers
- set up an alias domain
- create an SO and send it by email
(you can catch the sent email using mailhog)
- reply to that email
(you can use the support-tools[1] and set In-Reply-To: "previous message_id")
Bug:
the reply_to field of incoming message defaults to the first company
Fix:
set the reply_to field to the company asociated to the record
(there's already a fallback to self.env.company in
"_notify_get_reply_to_formatted_email")
opw-3060214
[1]: https://github.com/odoo/support-tools/tree/master/scripts/mailclosesodoo/odoo#115090
X-original-commit: d86e57404d540762fa51afeabeddd3a0fc45d4d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*=hr_timesheet,project,sale_project,sale_timesheet
Currently, the configuration of the recurrence is quite complete
and allows a lot of flexibility, but it is costly
in terms of implementation as it requires a lot of fields.
The goal of this task is thus to simplify this implementation.
In addition, a lot of people are complaining
that tasks are only generated when the recurrence date is reached,
as it doesn't allow to anticipate the planning of field service tasks.
In this task, we are thus going to immediately generate a new task
once the previous one is marked as done.
Concretely, we:
- describe a recurrence in terms of
"once every n day/week/month/year for ever/until a date"
and delete all fields that don't fit into it.
- remove the cron. The new occurrence is created when
marking the last task as done, and copied from the latter.
Deleting the last task deletes the recurrence.
The recurrence fields stay useful, as they form a delta t
that will be added to deadline/planned dates fields to get the new
values.
- use an boolean icon button to activate recurrence,
and place it at the end of deadline field's line.
The recurrence fields appear on the next line.
- delete in the form: the div explaining when the next tasks will be
created and the header to choose how to save the changes in the
recurrence.
task-3084945
closesodoo/odoo#112764
Related: odoo/upgrade#4343
Related: odoo/enterprise#37114
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When trying to invoice undelivered quantities the error message
was somewhat misleading: it indicates as a possible solution a
Stock app feature even when Stock is not installed.
After this commit the message will be more appropriated.
opw - 3206001
closesodoo/odoo#115033
X-original-commit: a6ae8fae9f0db559880e04caa8446e57f7733c85
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Since [the merge of the frontend into the backend] and more precisely
since [this commit], clicks on some elements makes the user switch from
the backend view to the frontend view.
Steps to reproduce (just an example):
- Go to /blog from the backend (/@/blog)
- Click on a tag (eg: adventure)
=> users are redirected to the frontend view, we do not want that. This
commit makes the user stay in the backend. For some scenarios (like the
one above), we create a fake form and submit it. The forms have a target
attribute that specifies where the form response should be displayed.
This commit set back the default value for the target attribute when a
user clicks on a blog tag, a course tag, the pager, ... so that the
response is displayed in the current context (the iframe when the user
is in the backend).
Note that [this commit] introduced the target attribute change to fix
two issues:
1. The opening of the payment gateways in the iframe.
2. The create page from a 404 page in the backend.
After [this other commit] has been merged, to prevent the first issue so
here we just remove the target attribute change except for the case of
the second issue.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this commit]: https://github.com/odoo/odoo/commit/2d44f2792dec0b2f205475a22dbedc97e9c54a64
[this other commit]: https://github.com/odoo/odoo/commit/3a32b9e1efa6277b345dc9239334680651690df7
task-3054970
closesodoo/odoo#114056
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Create a PO:
- Add a product
- Add a note or section
- Go To Alternatives:
- Click on “Create Alternative”
- Add another vendor
- Try to validate
Problem:
An error is triggered: “The operation cannot be completed: Description
(name) is mandatory”
The “display_type” and “name” fields must be copied in the vals to
create a `purchase.order.line`
opw-3164863
closesodoo/odoo#115070
X-original-commit: 66f806399d173f53b61db80b81d06a93421c75a3
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Update the UK tax names in accordance with the "taxonomy"
format (task-id 3052677).
EU Taxes have been changed to better reflect their current use (in
Northern Ireland only), and made inactive by default.
closesodoo/odoo#113363
Task-id: 3196842
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
This commit is to convert the "stock_report_generic" client action into owl.
closesodoo/odoo#112064
Taskid: 3175084
Related: odoo/upgrade#4309
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit:
=====================
KeyError 'selection_values' that occur in base_import/_handle_fallback_values()
while importing a data file. If any field(s) is many2one or many2many and we
tried to import the value of that field(s) that is not created in the database.
In that case when we set the 'Prevent Import' option.
It will raise an error like KeyError: 'selection_values'.
After this commit:
=====================
Solved the issue when there is a many2one or many2many field(s) and the import
value of that field(s) which is not available in the database. also, the method
is only for the 'selection' field and 'boolean' field so the code works when
there is a selection field and their selection_values only.
sentry - 3958065223
closesodoo/odoo#115056
X-original-commit: 0ef930cd7598bd15227ff025d2662d4331f8e45b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
To compute the analytic amounts, we used the user company currency
to know the precision to use to round, for the comparison.
We should instead use the line's currency for the amounts, and the
decimal precision for the distribution.
closesodoo/odoo#114997
X-original-commit: a94517702c47aa9259c0cbea9b4763ab7501176f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When the invoice is a New record and thus, not yet stored inside the database, the totals like amount_untaxed/amount_tax/amount_total are set to 0.0 because line_ids is empty.
About the lines, balance/amount_currency are also set to 0.0.
This means we can not rely to any of these fields in any case when computing the values for a New record.
To reproduce, configure the early payment discount computation to "Always upon invoice", create a new invoice and set the demo terms 30 Net 2/7.
For a customer invoice, the tax amount will not be correct until the save.
For a vendor bill, the tax amount will be erased by the quick edit mode and the correct value will never be set.
closesodoo/odoo#114994
X-original-commit: a34033524f6e1a2f46ce2e14368389ecddc3c840
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Current behaviour:
Down payments are taking into account in the project profitability in
the section "Other Cost". When invoicing fully an SO, the total sum
in profitability is the sum of the invoiced amount on the SO + the
down payment.
Expected behaviour:
Down payments should not be present in the project profitability, to
avoid incorrect sums.
Steps to reproduce:
- Install Sales, Accounting, Timesheets
- Activate Analytics in the Settings
- Set a Service Product that is invoiced based on fixed price
- Make sure that it generates a Project + Task
- Create a Quotation, confirm the SO with that product
- Create a down payment for 50% of the SO
- Confirm that invoice
- Create another invoice for the SO for the rest of the SO and
confirm it
- Go to the project's profitability tab for the SO, you can see that
we have the value of the SO + the amount of the down payment,
leading to an incorrect sum, in the section Invoiced.
Reason for the problem:
When taking the invoices for the profitability of the project, since
a down payment is another `sale.order.line`, we handle it in the
method `_get_revenues_items_from_invoices`, and there we are taking
into account the down payments.
Fix:
Elaborate the domain used to fetch the invoices in
`_get_revenues_items_from_invoices_domain` to not take those that
are down payments.
Affected versions:
- 16.0
- saas-16.1
- master
opw-3195016
closesodoo/odoo#115050
X-original-commit: ae151ec16a0054420f5c2827a1924c87e5b672ba
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Roy Le