Task 1883977
==== Purpose ====
Keep track of journal entries generated using the reconciliation model.
There is no easy way to see a summary of what journal items have been reconciled with a bank statement. This makes troubleshooting difficult. There should be a way to see the detailed history of which bank statement items were reconciled with which journal items.
==== Technical Specs ====
Make a many2one in account.move.line to retrieve the account.reconcile.model having generated this line.
(Make a computed many2many on account.move to the account.reconcile.model)
Add a stat button on the account.reconcile.model form view to retrieve journal entries more easily.
closesodoo/odoo#28752
Purpose of this commit is to make a single flow to sign and pay in the
customer portal. When having signed its document popup for payment is
automatically opened.
This is much better for usability and avoid to have orders being signed
and not paid because the customer did not see it was still to be paid.
This commit is related to task ID 1910532 and PR #29849 .
Since commit 34c47eecd3 wording of link when
sending a quotation by email is broken. Indeed has document in draft is
not correctly considered as having to be signed and/or paid the link is
not labelled correctly.
This commit fixes it. Parameter is also renamed to be more understandable.
This commit is linked to task ID 1910532 and PR #29849 .
Model methods should be private by default unless they need to be
exposed via RPC on purpose (e.g. for the web client).
The `send_forum_validation_email()` method is only called by a
controller and has no reason to be exposed via RPC, hence the conversion
to private.
Closes#30669
When filtering the calendar view on search filters, the filter `context`
was not taken into account during the reload.
For example, in the Calendar app, the filter 'My Meetings' has a `context`
{'mymeetings': 1} which was not passed to `search_read`.
Task 1917628
closesodoo/odoo#29531
opw-1916064
Have a sales order line on which you decrease the quantity.
Before, this commit, the warning message that says to update the
delivery order did not show. This was because, the onchange in the
python side compared the new quantity against the saved one, and did
not find any difference. This is caused by the onchange itself, which,
in a o2m setting, received from the JS, the changed order
(already containing the changed line) and only then proceeded to the
onchange of the line. The first operation wrote onto _origin the new
line value, which corresponded subsequently to the new value.
After this commit, we compare the real value explicitly retrieved from
the database to the one just entered by the user as an onchange.
The warning message works as expected.
Long story short, _origin in an onchange doesn't guarantee to yield
persisted values in all cases.
closesodoo/odoo#29582
instead of updating the cache by records.
We use `cr.fetchall()` and `zip` to get the values by field, which is more
convenient to be stored in cache.
Result of `cr.fetchall()`:
```
[
(3, 'Marc Demo', 'demo@example.com', '032'),
(1, 'Mitchell Admin', 'admin@example.com', '001'),
]
```
After being grouped by field:
```
[
[3, 1],
['Marc Demo', 'Mitchell Admin],
['demo@example.com', 'admin@example.com'],
['032', '001'],
]
```
That way we can update the cache of a field for all records at once, by calling
the builtin `update` method of `dict` with the `zip` of record ids and
corresponding values.
This significantly speeds up the storage of field values in the cache.
closesodoo/odoo#30817
Instead of iterating on self and then putting the values in the right place in
the `data` dict, iterate over data directly.
This removes the need of the indexing `data[record]`, which takes a significant
time when dealing with hundred of thousands of records.
Calling `len` on a long list and checking that its value is 1 is slower than
just unpacking the list. The point is to check whether there is just one item
in the list, and counting all items just for that is a bit overkill.
Use `env.registry` instead of `env` to get the comodel as a class instead of an
instance, which saves one call to `_browse` each time we access a relational
field. This saves time because of the cost of `object.__new__` and prefetch
update in `_browse`.
The cache is quite time critical, as it is accessed millions times when reading
multiple fields on hundred of thousands of records.
Avoiding indirections and `if` statement when possible speeds up the cache
access time.
- Portal users do not have the rights to read on project.project.
This causes issues on the page "/my/tasks" as it is trying to read the label_tasks and the name of the tasks' project.
To address this issue we read those two fields using sudo
Fixes#30127
opw-1925720
closesodoo/odoo#30955
- The field `signup_valid` was computed and stored using the `superuser`
env, which causes issue since it means the value was computed for the
wrong environment.
Using a compute_sudo instead of manually calling `sudo()` fixes the
issue.
e.g: reading signup_valid using a regular user (non superuser) will
always return False, while doing it as the superuser will return
the correct value.
closesodoo/odoo#30954
- Install a second language, e.g. French
- Set Parter A language to French
- Create an invoice for A with a date due in the past
- On the partner form view, print the 'Due Payments'
The body of the letter is not translated in French.
Something quite weird appears:
- The corresponding string is exported in the `stock` module
- It is linked to the demo data `stock.res_company_1`, which corresponds
to 'My Company, Chicago'.
Therefore, the translation cannot be found by the corresponding query
generated in `_generate_translated_field` and `_read_from_database`:
```
SELECT "res_company"."id" as "id",COALESCE("res_company__overdue_msg"."value", "res_company"."overdue_msg") as "overdue_msg" FROM "res_company" LEFT JOIN
(SELECT DISTINCT ON (res_id) res_id, value
FROM "ir_translation"
WHERE name='res.company,overdue_msg' AND lang='fr_BE' AND value!=''
ORDER BY res_id, id DESC)
as "res_company__overdue_msg" ON ("res_company"."id" = "res_company__overdue_msg"."res_id")
WHERE "res_company".id = 1 ORDER BY "res_company"."sequence" ,"res_company"."name"
```
Indeed, `res_company.id` is 1, while `res_company__overdue_msg.res_id`
is 3.
The root cause has been solved in v11, to we only export the necessary
term.
opw-1908337
closesodoo/odoo#29525
After this fix, the field `partner.street` is correcly rendered,
but as the test shows the `street_name` and `street_number` fields
are not correct.
But as there are tests that validate that wrong use case, I
consider it a *feature* and not a bug.
opw-1896773
closesodoo/odoo#29520
- Buy on product on the eCommerce with a partner having a single address
- At address selection, edit the shipping address
The billing address is also modified.
From the Odoo PoV, this is expected since they point to the same
partner. But from a user PoV, this is totally unexpected and confusing.
Therefore, we only allow the edition of the shipping addresses which are
different from the billing address. Yet, if the user modifies the
billing address, it will change the corresponding shipping address as
well. However, the usual flow is to set the billing address, then the
shipping address. So that should cause less issues. In v12, a warning
message is added.
opw-1914185
closesodoo/odoo#29509
This commit removes the attachment button from the sidebar.
Reason:
following the introduction of the attachment button in the chatter (7f97c9fc05)
and the partial removal of this feature (1dbb555aab) in V12.0,
it has been decided that the chatter button will completely replace this feature.
closesodoo/odoo#29468
Before this commit, when we crate a sale, we use the team_id of the partner
even if a saleman has been assigned from another team.
Now we use the saleteam of the saleman if it exists before the saleteam directly.
Task-phung
Fixed case:
Partner are created from lead assigned to Partnership
So team_id on partner are Partnership
After, we assign a saleman to the partner from AM
At each SO, the team_id is Partnership instead of AM
closesodoo/odoo#30549
If employee had the same address_home_id as it's user_id.partner_id then
we counted twice the same car.
Eg: specify address_home_id on demo user using it's partner, system
would have counted two cars. But demo has only one car
closesodoo/odoo#30546
Commit 55a48e3 added support for computing car count and car reports
for employees without a linked user..
It is computed by accessing the field `address_home_id` (res.partner) to find the driver.
However, this field is private.
Therefore a user in `fleet_group_manager` has an ACL error when accessing
an employee form view which contains a stat button with the car count.
This commit compute the car count and the car report
with `address_home_id` as sudo to fix the issue.
Also fix a typo in attribute `groups` instead of `group` and fix its
value from `fleet_manager` to `fleet.fleet_group_manager`.
Before this commit, notification_read raise a traceback on some button click.
Eg: Flag/unglaG
It was hidden in the console, but we can just avoid it too
closesodoo/odoo#30524
Force image to stay in their container (img_fluid could be removed by end user)
Stop to use row_users
now that we use bs4,
allow to be more responsive,
force height to be the same for each card.
Small imp replacing multiple if by elif
Decrease big margin between questions
Place tag on the top (if you have many tag, or very long, the ui is broken)
Before this commit we try to imitate the btn with the form (eg. flag button)
But if you style in a theme your button and not the form (like odoo.com) you
will see a difference between the 4 icons.
Purpose
=======
GST Invoice Report required to show tax amount product line wise.
This Tax amount is divided in CESS and IGST or CGST and SGST.
Improve GST Tax, Tax Groups and Tag.
Reverse charge under GST
As per GST rules tax will have to be paid directly by the receiver to the Government instead of the supplier.
Reseller(E-commerce) under GST
If you sale through ecommerce then need to specify ecommerce GSTIN.
Import/Export goods under GST
If you export the goods then need to specify
-Export Type
-Shipping bill number
-Shipping bill date
-Shipping port code
Credit or Debit Note
If u give Credit or Debit note then need to specify Refund reason.
Place of Supply is the state of customer.
Added GSTR reports
GSTR Invoice report covers below GSTR-1 sections(this report is grouped by tax rate and journal entries
B2B, B2CL, B2CS, EXP, CDNR and CDNUR
GSTR payment report
This report is covered under GSTIR-1 section called AT(advance payment) and ATADJ(advance payment adjustment)
GSTR HSN report(it is based on the product HSN code)
GSTR Exempted report(it is based on nil rated and exempt tax)
This report is covered under GSTIR-1 section EXEMP
Added demo data to to have GSTR-1 reports out of the box
Solution
========
fetched values of CESS, IGST, CGST and SGST amount in invoice report from tax groups
added new taxes called "Nil Rated" and "Exempt" and also added it's related tax groups and accounts
added tax tags related to GST tax percentage
Set Reverse charge in negative tax
Improved account move line creation grouping machenism:
Now, move lines related to tax are grouped by product and uom instead of grouping them just by tax(this is for better reporting)
closesodoo/odoo#30332
The field tax_ids on account.move.line created from an invoice was incorrect in case of a tax with children with type_tax_use!= 'none'. Hence, the tax_base_amount and the whole tax statement was wrong in that specific case.
Was part of (although not related) the PR #26262
* Allows to overwrite and change the account.move.line values that will be created upon a pos session closing for example to add additional data introduced by a localization module.
* Small refactoring of _create_account_move() method: All the parameter values of _create_account_move could easily be found from pos.order recordset itself, hence removed them and adapted call to it everywhere.
Part of PR #26262 related to the indian GST
Since the control panel refactoring, the `context` key on a `<field>` in the
search view was ignored (like <field name='pricelist' context="{'pricelist': self}".
The previous behaviour has been reintroduced and modified a little bit.
For way too long, an ugly hack was used to get a numerical value in self. This
ugly hack was still present but wasn't working since 8.0 (at least for the
numerical value). A counter hack (see odoo/odoo@4a81e8a) was then applied to
avoid really using a `selection` widget. To get even more confused, `self` was
replaced by the *last* user-specified value.
Well, it's time to clean this mess.
Now, the `self` key is replaced by an array of user-specified values (by value,
we mean the field value i.e. the `id` for a many2one, or the `key` for a
selection field).
Task 1902826
closesodoo/odoo#30368
Seems better to have wrong term for lead an correct for opportunity
that have not wrong for Lead an not wrong for Opportunity.
task-1932070 related to b6f4d97
closesodoo/odoo#30482
Until now, you cannot find easily if it is a lead or an opportunity that
has been created.
"Opportunity created" is written in the log but it is in reality a Lead.
Now we track the change on the field type to know what was the type at the
creation AND when it has been converted to opportunity.
task:common-sense-in-real-life
wan