The model inheritance concept was explained with abstract example which is
often confusing.
Change to a real world example that will be better understood.
closesodoo/odoo#27396
The received quantity on Purchase Order line can be compared
to the delivered qty on Sales Order line. It is now time for
both to share the same mecanism (introduced in
3bf8a62e0d).
This commit sets `qty_received` as a computed field, depending
of a method (`qty_received_method` field) to compute it. The
value can be computed based on
- manual value; for services (all the time), and consummable
products (when stock is not installed).
- stock moves; for stockable and consummable products (when
stock is installed)
This is now easier to extend the way the received quantity
need to be computed (like in sale).
Task #1850689closesodoo/odoo#27663
This commit fixes the following bug:
* On a new DB, install account
* Settings > Technical > Email > Digest emails
* Open Weekly Digest, set Next Send Date to current day
* Settings > Technical > Scheduled Actions > Digest Emails
* Run manually
AttributeError: 'res.company' object has no attribute
'resource_calendar_id'
The field resource_calendar_id is provided by the module resource
closesodoo/odoo#28239
Purpose
=======
Before this commit, it was not straightforward to use leave records in salary
rules programatically.
This commit implements the standard and python-code compatible way of defining
leave codes which then can be used in the salary rules in the used way.
This way, the naming of leaves will not be restricted to python-attribute
compatible naming, when one wants to use this feature.
Leave names (translatable) are an unreliable identification in python code salary rules.
A language switch would break python salary rules that use a leave type as input
TaskID: 1903964
Closes#28240
Co-authored-by: blaggacao <david@elaleman.co>
Purpose of this merge is to clean a bit link_tracker and utm as well as their
use in mass mailing. Main things done in this merge are
* reorganize link_tracker and utm according to guidelines. Purpose is
to ease code understanding and prepare future improvements in those
modules;
* clean views, add missing fields in views;
* better integration of link menus and views in mass mailing;
This commit is related to task ID 1896681.
closesodoo/odoo#27975
Purpose
=======
Some parts of the code are quite old-api-style and could be modified to use recordsets and thus improve performances.
closesodoo/odoo#28182
Purpose is to ease use of mass mailing by improving the action linking to
statistics. Form / graph view is added as well as informations related
to mass mailing and campaign.
This commit is linked to task ID 1896681 and PR #27975.
Purpose
=======
These classes are utils classes for the payslip computation.
It's better for the code readability to isolate them into a single file,
and keep the business logic into the payslip model code.
Purpose
=======
This method has nothing to do on the payslip model.
Specification
=============
Move the method on the hr_contract module, on the hr.employee model.
Rename the method and return and recordset instead of a list of ids.
Some variables were placed at the beginning of the backend helper.
While it was working, the normal convention is to place them at the
end of the variables helper.
closesodoo/odoo#28203
Purpose is
* to clean a bit views;
* to improve link.tracker form view to have information better displayed;
* to remove unused views;
This commit is linked to task ID 1896681 and PR #27975.
This was not correctly done when splitting the module at fd5361c0f7.
Future commits will clean a bit the code in order to better understand how
this module works.
This commit is linked to task ID 1896681 and PR #27975. No functional change
should occur with this commit as it contains only renaming / move.
This module still holds old code and deserves some love. This commit cleans a
bit the init and manifest files as well as renaming view file according to
guidelines.
This commit is linked to task ID 1896681 and PR #27975. No functional change
should occur with this commit as it contains only renaming / move.
Purpose is to give a quick polish to this module code concerning views.
Some ids are updated, indentation is fixed.
This commit is linked to task ID 1896681 and PR #27975.
This module holds old code and is still not updated according to guidelines.
Let us update a bit the naming in this module to have readable code.
This commit is linked to task ID 1896681 and PR #27975. No functional change
should occur with this commit as it contains only renaming / move.
Before that, the body of the message was never displayed if the message had tracking values. This was annoying for account_asset module, were we prompt the user for some justification when she modifies the depreciation data of an asset, and then call message_post with this text as body, and tracking values reflecting the change that was made.
Spamming the "send" button on the chatter send multiple times the
same message. This PR simply disable the send button to fordib the
spam.
opw-1895511
closes#27233closesodoo/odoo#28078
Steps to reproduce the bug:
- Create a credit note for an amount of 100$
- Validate it and register a payment
- Let's pay an amount of 90$ and mark this credit note as fully paid
Bug:
An error message was raised saying: Wrong credit or debit value in accounting entry !
The field residual_company_signed must be positive for out_invoice and in_refund and
negative for in_invoice and out_refund. In this way, the correct writeoff amount
can be computed in function _create_payment_entry.
PS: In function _compute_payment_amount, the field residual_signed and residual_company_signed
are already signed, that's why it was wrong to multiply a second time on it with MAP_INVOICE_TYPE_PAYMENT_SIGN
opw:1893570
closesodoo/odoo#28148
It appears that chrome headless with sandboxing is failing when running
containerized because it tries to use Linux namespaces.
With this commit, the no-sanbox optional arg is used to avoid this
issue.
Closes#26456Closes#28053
Given a country code is specified and the country only has one timezone, it is
safe to assume that the admin user is operating from that timezone.
Set the default timezone to simplify the onboarding in such particular case.
If a country has more than one timezone, we can not make safe assumptions and
don't provide a default tz.
closesodoo/odoo#26365
If a supplier had a refund, it was not included in the supplier invoice count
nor in the results in the statbutton
On the customer side, fields like total_invoiced works on both the out_invoice
and out_refund
closesodoo/odoo#28161
Before that, when receiving, then invoicing with price diff, the value in interim account corresponded to the price on the invoice instead of the original valuation one.
Scenario to reproduce the issue:
* create PO with 1 product, FIFO valuation, price=10
* receive PO: the entry in stock interim account has debit=credit=10
* create invoice, with price=15 instead of 10
* the invoice entry should be: payable: C=15 ; price diff: D=5 ; interim account: D=10
==> Instead, we had payable: C=20 ; price diff: D=5 ; interim account: D=15 => this was wrong
Also added a test case for the same scenario, verifying the amounts written in the different accounts (and refactored a bit ValuationReconciliationTestCase for easiness)
Closes#27394
From times to times, warning are seen on the runbot during HttpCase
tests with the chrome headless browser.
Those warning are about Odoo trying to join remaining requests threads.
In the dumpstack, the thread seems blocked in the werkzeug
handle_one_request method, when trying to read the HTTP request line.
One explanation could be that Chrome opens a pre-connect socket for
a future use. When the HttpTest cleans the browser, the page stops
loading but (probably) keeps the socket open for a while.
That could explain the problem.
With this commit, a timeout is set on the request handler,
in the hope that it closes the pre-connect socket too.
If a supplier had a refund, it was not included in the supplier invoice count
nor in the results in the statbutton
On the customer side, fields like total_invoiced works on both the out_invoice
and out_refund
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
opw-1883693
- Create 2 Products A and B, tracked by serial number
- Create a BOM for A:
1 Unit of B
- Create a MO for 2 Units of A
- Validate:
Product with S/N A1 consumes B1
Product with S/N A2 consumes B2
- Unbuild A2
If A1 was created before A2, B1 will used as a component of A2 at
unbuild.
When going through the stock move lines, we don't verify that the lot
produced matches the lot we unbuild.
opw-1889002
closesodoo/odoo#28154
before fix:
in firefox the textarea of note modal has a overflow
textarea can be expanded outside borders modal in all browsers
closes#25199closes#25215
issue 1895298
If the search returns more than one result, the rendering of the message would
crash (SingletonError when accessing check_in field value).
Use the same order and limit as both search before and after
Courtesy of David Tran
Closesodoo/odoo#28055
before this fix it was not possible to connect to the pos/iot-box using
https on the pos. By checking if the pos is http or https this is now
possible after accepting the certificate.
if https scanning for proxy is disabled, the user should always give a
ip in the configuration
Otherwise, the product is a service based on delivered
quantity which is not a covered case by the service_policy
field on product form view (the selection will be empty).
Asked in Task-1859308
closesodoo/odoo#28162
Apparently missed in 07ab8b6cd2
In Python 3, there is no Exception.message attribute anymore, this would
lead to cascading exceptions in the stripe_s2s_create handler.
closesodoo/odoo#28141
Robot Odoo