Fine tune the module to improve the business flow:
1/ Allow to force the presence of an employee
2/ Don't notify followers when sending a email
3/ Open the leave request form instead of the leaves list
closesodoo/odoo#28483
On a hr.leave creation on the form view, the fields request_date_from and
request_date_to are set on today. The fields date_from and date_to are set on
now.
We have 2 onchange methods:
- _onchange_request_parameters: Set date_from and date_to according
to the leave configuration.
- _onchange_leave_dates: Set number_of_days according to date_from
and date_to
As _onchange_leave_dates is called before _onchange_request_parameters,
the field number_of_day is always set to 0, even if the leave is taken
for all the day (the default value).
It means that if you don't modify the dates, the value stored in the
database is incorrect.
We have to call manually the method _onchange_leave_dates at the end
of the method _onchange_request_parameters execution to ensure
the validity of the value.
In the compute function _compute_move_without_package, we use self
instead of picking variable, which leads to traceback when more than one
picking is computed
closesodoo/odoo#28482
Purpose
=======
1/ A team leader is not able to validate leaves for his own team.
2/ Another person than the manager can be supposed to validate the leaves for a certain employee
Specification
=============
1/ New hierarchy: Team Leader < Officer < Manager
People in Team Leader access group will now be able to approve leaves for employees in their team.
- Added the new access group
- Added rules for people in this group to read or write appropriate records
2/ Add 'leave_manager_id' field on employees to refer to the Team Leader.
- Added the new field to Employee model
- Added the field to the view so that it is visible
- Modified a filter in a view so that it is more relevant according to its name (My Team Leaves)
- Added a filter in a view for managed employees
TaskID: 1888653
closesodoo/odoo#28352
When loading the Reconciliation Widget, all reconciliation models are
retrieved. This is not correct: only the one matching the company and
the journal should be retrieved.
Fixes#28270
opw-1904475
closesodoo/odoo#28474
Consider the generation of an invoice for a SO having the following lines:
quantity | unit price | taxes | subtotal
----------------------------------------
1 | 100 | 15% | 115
1 | -110 | | -110
Previously, the invoice wrongly received the type 'out_refund' instead of 'out_invoice'. This was because the code was only considering the untaxed amount.
Closes#28259Fixes#26726
Co-authored by pedrobaeza
Purpose :
=======
On the Contract form view the field label for the "contract type" is "Employee Category".
Then it will be good if we keep the same label on the group by also...
Right now on the Group By it is "Contract Type"
closesodoo/odoo#27560
Before this commit, when there was several previews
on the messaging menu that were not linked to any
document, marking one of them as read had the unintended
behaviour to mark all of them as read.
Steps to reproduce:
- Admin with notification management as 'Handle with Odoo'
- Demo assign Admin to two different tasks
- Admin mark one preview as read
> Both previews notifying assignment to a task have been
marked as read
This is caused by the fact that messages of those previews
are not related to any document. As a result, when marking
one preview as read, it maps related messages to mark as
read, which was taking into account all messages that are
not related to any document.
With this commit, previews now tracks message IDs, so that
marking one preview as read only mark the related messages
as read.
Task-ID 1907159
Before this commit, when the user clicked on a preview in the systray
messaging menu that is not linked to any document, there was a
traceback.
Steps to reproduce:
- Admin sets notification management to "Handle with Odoo"
- Demo user assigns Admin to a task
- Admin clicks on preview from being assigned to a task
Those are previews from notifications received from the inbox,
which are not related to any document. It attempts to open a
document that does not exists (i.e. no model/id).
With this commit, when such a preview is not linked to any
document, it now opens Discuss with Inbox.
Task-ID 1891350
Before this commit, if you ask for a small image, you was waiting a picture of
64x64 but in case this image was not found, a placeholder with an other size
was returned.
Now, we try to guess the asked size, and return a resized placeholder.
This bug appear since we change the default placeholder picture with a big one
This will fix several issue and avoid to hard code size everywhere in the code
Eg: commit 92f837c and commit https://github.com/odoo/odoo/commit/154fc7d9dd550d35b7266af024e54c20e18938fc#diff-9af1af2039d16d6b544d481b4ee1ed7cR144closesodoo/odoo#27695
Before this commit, RTL on frontend was only enabled for connected user.
To have RTL, we add the direction on the element, and the RTL version of
the stylesheet for the applicable languages are generated thanks to rtlcss.
opw-1892757
closes#28434
Odoo 12.0 does *not* officially support any python version below 3.5,
but no effort had been made to gracefully announce this to the end user
if they were to run Odoo in an unsupported python version.
This is done because Odoo 12.0 uses py3-only constructs which can
and will raise different errors if ran in python 2.
With this patch, Odoo will display an appropriate error message and won't
launch at all unless it is being run with python 3.5 or greater.
closesodoo/odoo#28502
Suppose you are editing a SO to add a new line. Depending on the configuration,
a sale order line wizard may open (e.g. if packages are activated).
This wizard is a form view, opened from the tree view of the sale order lines.
We have commit 8e5156938a
that adds extra fields from the originating view.
(However it doesn't work if the other view is inlined, so we modify this part to
add the extra field even in this case.)
Then we need the field info from the origin view in the target view;
we do so by extending the former with the content of the latter.
opw 1904337
closesodoo/odoo#28441
Stock moves show a detailed operations icon if the tracking, locations, or
consignment allow to be configured.
However it did so on a per move basis, only displaying it if the considered move
has some of these features.
This fix makes it that the "detailed operations" icon is always displayed if at
least one group of group_tracking_lot, group_stock_multi_locations, or
group_tracking_owner is active, or the move is tracked,
unless the move picking type already does show detailed operations.
opw 1893106closesodoo/odoo#28072
Create an automated action to create a new activity on update of a record
(e.g. a CRM lead).
At update, many fields recompute may be triggered, triggering as many write.
Thus it would generate many activities.
We simply do nothing if we are in a recompute.
Coauthored by rco
opw 1904156
closesodoo/odoo#28498
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
Also the behavior of not clearing the message if there was an error is
introduced back.
Without change in code, added test fails with:
"Should keep unsent message in the composer on failure" (result: "")
"Send button should be re-enabled on message post failure" (result: true)
issue found when checking opw-1904029
closes#28475
- Create a SO
- Paid the SO using a transaction
- Create an invoice from the SO
=> The invoice will now be reconciled automatically with the payment transaction
Was task: 1890029
Was PR #27390
Before that, with "post at bank reconciliation option" activated on bank journal, the following scenarii did not work as expected:
1. When creating an invoice, making two payments for it, and then matching only one of them with a bank statement
=> the invoice was marked as 'paid' while it should have staid 'in payment' until the second payment gets a bank statement.
2. When directly reconciling a bank statement with an invoice for its full amount
=> the invoice staid in "in payment" state, while it should have been "paid"
[IMP] account: add tests for the aforementioned cases
closesodoo/odoo#28428
Sometimes, a sale.order in the SALE state doesn't have a confirmed date,
which can cause a traceback. To avoid this, when confirmation_date is
null, use the write_date, which is never NULL when sale.order is in sale
state.
In migration, we will try to populate the confirmation date with
the mail.message subtype. As ultimate fallback, we will take
the write_date.
closesodoo/odoo#28296
Create an accrual leave, and set it e.g. by employee tag.
For each employee having the tag, a child allocation will be created.
When doing so, it will prepare the values for these creations.
However the relevant fields for accrual leaves were missing from these values.
opw 1906476
closesodoo/odoo#28492
1. Create a payment term with:
- 50% due now
- balance due in 14 days
2. Validate an invoice with this payment term and partner Agrolait
3. Create a payment from Agrolait with the 50% due
4. Add this outstanding credit to the invoice
It is reconciled with the balance due in 14 days instead of what is
due now. Because of this e.g. the Aged Receivable report will show the
customer being overdue with a payment.
This issue was first fixed in 9.0 at
adad192cc0. It was then reintroduced in
saas-11.4 at d3d2612061. This commit
adds a test to avoid regressions like this.
To fix the issue this sorts journal items by their Due Date if there
is one. Otherwise we use the date from the journal entry as before.
Note that before this commit journal items were not sorted at all by
the two 'sorted' statements. sorted returns a sorted recordset, it
doesn't modify the recordset it's called on.
opw-1906665
When changing the field `image` on `res.users`, the `write_date` of the user is
not updated because the field is inherited from `res.partner`.
Related to Issue : 1839603
This code is called by account_reports to build the Aged Receivable/Payable.
However, no support for the multi-company/multi-currency is there and then,
the multi-company filter on account_reports never worked.
In a multicompany environment, an user who has access to multiple companies is
able to select accounts and analytic accounts of multiple companies. This can
easily lead to mistakes in the definition of the asset category.
With this commit the user can only read/select accounts and analytic accounts
belonging to the company already set in the asset category.
This is what is already done in most invoice or other accounting views
Closes#26578
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
payment_term.id, creates a tuple wich works if payment_term.id is set
in case payment_term.id is False this creates the tuple (False,) which
is then converted by the Odoo ORM to a account.payment.term(False, )
record set, which in term may cause weird behaviour as this value does
not eval to false in cases like `if self.payment_term_id:`
Closesodoo/odoo#28397
Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
Robot Odoo