Before this Commit,
While creating a custom appointment, The appointment name has 'Username'
and invitation email also has 'Username'. When a customer receives the
invitation email, The 'username' gets twice.
After this Commit,
We have removed the 'With username' part from the default email template.
Task-2713963
closesodoo/odoo#82894
Related: odoo/enterprise#23197
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Enterprise PR - odoo/enterprise#23980
Upgrade PR - odoo/enterprise#3206
- UI improvements/changes
- Taxes
Before this commit, in case taxes were defined on expense,
the tax amount was added on top of a product price.
For example, in case product price was 100$, and tax - 15%,
then expense.total_amount would be 115$.
Now, tax amount is included in expense.total_amount. To accommodate
this change, we set following domain - ('price_include', '=', True)
on tax_ids on expense.
For the same example, expense.total_amount would be 100$, tax amount
would be 13.04$ and untaxed amount - 86.96$.
But, tax amount can be set for non-zero expenses (in case expense.product_id.standard_price !=0).
For the above example, one could set tax amount to 15$.
As a result untaxed amount will be 85$ and total amount - 1OO$.
- Journal entry
Previously, in case journal entry was reset to draft, canceled,
reversed - it changed the state of the linked expense report.
Now, actions done on accounting by accountant does not impact expense reports.
task - 2687999
closesodoo/odoo#81904
Related: odoo/upgrade#3206
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
"True" and "False" are not very user-friendly, especially for
non-technical people. Instead, we want to have "Yes" or "No" which have
more sens for non-technical people.
This change is done for the the custom filter and the tracking messages.
Task-2648390
closesodoo/odoo#79911
Related: odoo/enterprise#23863
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
When we group the record based on a boolean fields, we want to show
"Yes/No" instead of "True/False".
This has been done for the list view, the pivot view and the kanban
view.
Task-2648390
Part-of: odoo/odoo#79911
Purpose
=======
When the value of a tracked boolean field change, we can see in the
chatter "True -> False". It doesn't have that much sens for
non-technical people, and instead we want to use "Yes -> No".
Task-2648390
Part-of: odoo/odoo#79911
Purpose
=======
"True" and "False" are not very user-friendly, especially for
non-technical people. Instead, we want to have "Yes" or "No" for the
custom filters, when we search on a view, which have more sens for
non-technical people.
Task-2648390
Part-of: odoo/odoo#79911
Part of the overall v16 SCSS optimization/restyle (task-2704984).
task-2731819
closesodoo/odoo#82590
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Some recent changes have evidenced that the modification of the activity
type of an 'upload_file' activity was not properly covered by the tests.
This commit adds a new test for this specific case.
Part of task-2730667
closesodoo/odoo#82498
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When clicking on a mention (or a link) within the preview of the
message we're replying to, there was a traceback because we tried
to update a component which has already been deleted.
closesodoo/odoo#83912
Task-id: 2747321
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When searching sale order lines from another model (e.g. task), the
order number was not being considered.
The technical reason for the above is the resulting domaing was like this:
[
'|',
('order_id.name', 'ilike', 'SO name'),
('name', 'ilike', 'SO name'),
# The below line is added by _name_search of base model
('name', 'ilike', 'SO name'),
])
So, even though the order number is added to the domain, an extra
condition was forcing the line description to be the only field to be
considered.
closesodoo/odoo#83911
X-original-commit: b5d45d6cae3579970ed55bc65d52c2de2377c381
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
To reproduce :
- Create a new documentation course from front-end
- Add a content there
- Edit the course in backend
=> any attempt to save the record or exiting it will trigger an error
as the specific option is set and no content has been manually set.
This has been introduced in 2597345
=> We restore the default 'latest created' that makes it work all the time.
Task-2731468
closesodoo/odoo#83910
X-original-commit: 1973944c0cdd0ea3f706280875acedfbd190333e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Shipping insurance is a service which may reimburse senders whose parcels are
lost, stolen, and/or damaged in transit. Since most shipping connectors
provide it, it makes sense to put it in the base directory.
task-2701459
closesodoo/odoo#83896
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When trying to set up a new bank account using the bank account wizard,
there is an issue with the check company on the linked_journal_id field.
The check will make sure that the company on that field is either false
or the same as the company on the record. But with a recent change in
68f4534aa5 the bank account company_id will be the one from the linked partner.
As the partners for companies have an empty company_id, this check does
not make a lot of sense anymore, as it would be wrong in most cases.
(We expect a journal with the currently selected company, but the bank
account will in most cases have an empty company_id)
closesodoo/odoo#83852
Signed-off-by: Josse Colpaert <jco@odoo.com>
In 9f7e6d2bb6ae0a6b0257edf26a5aa069cd00d78e , when start a workorder, we
always suggest the qty to produce to be the full qty to produce on MO.
If the previous WO produced less than the full qty to produce on MO,
user won't aware of that when start the WO. We revert it in this committ
Task-2678388
closesodoo/odoo#83389
Related: odoo/enterprise#23961
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Storno accounting is the term used to described the process of recording
a reverse action as a negative amount on the same site instead of a
positive amount on the opposite site of the credt/debit.
For instance, when one creates a credit note for an invoice, the values
of debit and credit will be kept in the same column with negative signs
instead of swapping columns like in non-Storno accounting.
It is a business practice commonly used in Eastern European countries.
Countries where Storno accounting is mandatory or considered as best
practice would be :
Czech Republic, Poland, Romania, Russia, Slovakia, Ukraine, Croatia,
Bosnia and Herzegovina, Serbia, Romania, China, Russia, Slovenia
It is available as an option in the settings and is automatically
activated for some countries which use this type of accounting.
otask-2064899
closesodoo/odoo#79581
Related: odoo/upgrade#3212
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: qdp-odoo <qdp@odoo.com>
Users are able to create accounts without restriction on the type of account to be created. With this commit we provide a context key to limit available account types and thus minimise errors.
part of task-2684816
closesodoo/odoo#80831
Related: odoo/enterprise#22198
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior :
When creating an invoice from a PoS the description attached to the product was not the same as the one in the SO
Steps to reproduce:
- create a SO from Sales
- create an invoice from the SO
- preview the invoice
- open a POS session
- fetch the same SO
- validate the order with an invoice
compare the 2 invoices, they are not the same
opw-2674896
closesodoo/odoo#83833
X-original-commit: dbd766f1b87f91eefce7b6e5946856961fd96c70
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When comparing existing translations to new source value
html tag would invalidate existing translations.
The html tags used for styling (coloring, italic, ...) should not
invalidate the translation as the meaning of the text as not changed.
Changed the logic to compare translations based on textual content only.
+ add some tests.
task-2667950
closesodoo/odoo#83895
X-original-commit: 1fe4b0cc1981382cc3d944ec44276f0aee90945d
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
Co-authored-by: xmo-odoo <xmo@odoo.com>
When selecting the text content of a link
the underline and italic commands were not working in Firefox.
We re-implement the Browser command to fix this.
task-2667950
X-original-commit: 52a5b2bb692ab6712d497492f4f2fbef3a9a7874
Part-of: odoo/odoo#83895
Steps to reproduce the bug:
- Go to Settings > Technical > Decimal Accuracy
- Change Unit of Measure to 4 digits
- Go to Inventory report or Valuation report
Bug:
The decimal accuracy in Valuation report for quantity or reserved quantity was in two digits instead of four digits
The decimal accuracy in Inventory report for qty_at_date was in two digits instead of four digits
PS: In stock move report or stock move line report, the decimal accuracy of quantity fields are in four digits
By default digits of Product Unit of Measure is 3, that's why some test had to be modified
opw:2410981
closesodoo/odoo#82989
X-original-commit: 0cf5c4e8241c46724defc0ea7e0d2c881ec2eeab
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The method constraint to validate the Check Number is slow
1. Analyzing the following query:
```sql
SELECT
payment.check_number,
move.journal_id
FROM
account_payment payment
JOIN account_move move ON move.id = payment.move_id
JOIN account_journal journal ON journal.id = move.journal_id,
account_payment other_payment
JOIN account_move other_move ON other_move.id = other_payment.move_id
WHERE
payment.check_number::integer = other_payment.check_number::integer
AND move.journal_id = other_move.journal_id
AND payment.id != other_payment.id
AND payment.id IN (1085159)
AND move.state = 'posted'
AND other_move.state = 'posted';
```
The output is:
Planning Time: 3.354 ms
Execution Time: 2514.660 ms
Discarding null values
```diff
AND other_move.state = 'posted';
+ AND payment.check_number IS NOT NULL
+ AND other_payment.check_number IS NOT NULL
```
The output is
Planning Time: 3.216 ms
Execution Time: 0.140 ms
2. The constraint is computed even if the payment is not a check (check_number is empty)
Returning early save useless extra computating
It is not needed to compare falsy values for duplicated for whole table
3. The validation to check is it not a number is not optimal
It is transforming the string -> integer -> string to check if the string is not a number
but it is enough using only string -> integer not needed to transform to string again
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[str(int(i)) for i in check_numbers]"
> 1 loop, best of 5: 323 msec per loop
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[int(i) for i in check_numbers]"
> 2 loops, best of 5: 135 msec per loop
It is better but not enough, using `str.isdigit` method is 5x faster than original approach
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[i.isdecimal() for i in check_numbers]"
> 5 loops, best of 5: 64 msec per loop
closesodoo/odoo#83851
X-original-commit: 31e0ed8c957e8a6af7f6bd5d449b450967206eab
Signed-off-by: Olivier Colson <oco@odoo.com>
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
Before this commit, when a project has no SOL set and has an employee
mapping, then the domain builds in the search method of `pricing_type`
is the following:
`[
('sale_line_id', '!=', False),
('sale_line_employee_ids', '!=', False),
('allow_billable', '=', True),
]`
The problem is we don't need to have a SOL set into the project to
define the pricing_type as employee rate. We should find the project
with at least an employee mapping set in that project.
Moreover, this commit fixes the domain built in the
`_search_pricing_type` method.
Some unit tests are added to check the domain built in the
`_search_pricing_type` method.
The issue has been found during the development of task-2680425
closesodoo/odoo#83874
X-original-commit: 490747c85f2d2e390a44e8f375e24dc3a8425409
Related: odoo/enterprise#23951
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
To ease comparisons for query counters let us try to keep the same test flow
through v15+. We therefore now also compute recipient groups for portal users
for some test models, like before odoo/odoo@faeb5e7fee .
Part-of: odoo/odoo#83832
Usecase to reproduce:
- Create a planned receipt of 10 product A
- Set quantity done to 10
- Put in Pack
Actual result:
UerError "There is not move line to pack"
Expected result:
Pack them
It happens because since we are in a receipt without suggestion (by
default) then the fields `move_line_nosuggest_ids` is used.
But `_set_quantity_done` on `stock.move` will first try to fill
move line with reservation before creating new ones.
So the move_line_nosuggest_ids will not contain the quantity done
on planned quantity
closesodoo/odoo#83430
X-original-commit: 3c7453a61372d6ecdeae099d49cbc79844c144ae
Related: odoo/enterprise#23767
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usecase:
- Install mrp with demo data
- Log in chicago company
- Go to manufacturing list view
-> Access error is raise due to multicompany rule
It happens because the state.res_ids contains all the mrp.production
even in SF company. So it try to read records in the wrong company
and raise the error.
Instead of doing a read, we change that and do a search_read like in the
classic process using the state.domain. So it filter the wrong records
before reading them
X-original-commit: 2077ee3b9312fc511d8fd5d328b5c4e329d9b784
Part-of: odoo/odoo#83430
Usecase to reproduce:
- Create product 1 with supplier `Vendor` and a delay of 3 days
- Create product 2 with supplier `Vendor` and a delay of 4 days
- Create two procurements with a need for stock at 01-01-2022 (warehouse
1 step)
- Run procurement for product 1
- Run procurement for product 2
The PO contains the two product but the order date is for 3 days before
and not 4. Also the line for product 2 is planned for the 02-01-2022
It happens because the delivery date is computed base on the purchase
order date and the supplier but the procurement is totaly ignore
X-original-commit: aec7fcdb693729f432ae2341c00ef317b65fbcbc
Part-of: odoo/odoo#83430
Some projects start to have real planning and in multiple
steps the `stock.move` that are not linked to a RFQ or a MO
are always merge together with the minimal date are result.
It's not flexible since you don't know the correct quantity
for a specific day. And once this quantity is received, you
don't know the next date.
We just add a system parameter for now and it will be modify
in master to be able to do this configuration for everyone.
X-original-commit: b9fffac7a8b6ccef2d957b5564ce615b2e1b0b36
Part-of: odoo/odoo#83430
While the batch is currently visible on the tree view, there was no
current link to a picking's batch while in the form view.
Task-2670580
closesodoo/odoo#81533
Related: odoo/upgrade#3205
Related: odoo/enterprise#23484
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When adding a selection of pickings from the list, select the 'create a
new batch' over 'add to existing batch' as it better reflects user's
usual flow.
Task-2670580
Part-of: odoo/odoo#81533
Improves the auto-batcher, allowing it to also group by :
- Carrier
While adding a new restriction on the batch size as well :
- Max weight per batch
Task-2670580
Part-of: odoo/odoo#81533
Allow confirmed pickings to be automatically put into batches that match the
group criterias defined in their picking_type.
The pickings can be grouped by :
- Contact
- Destination Country
- Source location
- Destination location
To avoid having batches too big then, some restrictions can be put over
the auto-batcher to restrict the size of a batch :
- Max moves per batch
- Max pickings per batch
Task-2670580
Part-of: odoo/odoo#81533
Since [1], the test suite waits for 5s to start running. It's
really annoying when you run the suite in your browser, to debug
a single test or a sub suite. Waiting for 5s to determine whether
all modules can be loaded or not is not necessary anymore since
all assets coming from the same bundle are loaded in a single
file, even in debug=assets. This is true under the assumption that
there's no js module in assets_common requiring a module in another
assets bundle, which seems reasonnable.
[1] 468eb84fb4closesodoo/odoo#83805
Signed-off-by: Géry Debongnie <ged@odoo.com>
Mitul Shah