When a pos session is closed, the difference and transactions of cash
control are not good anymore, because it is based on the statement
linked to the cash payment method, and it is modified during the
validation of the session to create a balanced account move.
So we are now storing the values in fields, to keep history of the
closing control
closesodoo/odoo#35286
Task-id: 2032173
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Non-ascii characters in LDAP don't cause a python unicode string in
returned ldap entries, this commit fixes this.
Before this commit, further string operations on ldap values with
non-ascii characters fail.
closesodoo/odoo#40761
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
On mobile, there was no way to create a new column in the kanban view. This
was specifically annoying in the Project app (the user was able to
create the project but couldn't set its stages).
This commit enables this feature by adding a `+` icon at the end of the
tabs. This button opens a quick-create column widget.
If there is no existing column (for example in a newly created project),
this quick-create column widget is opened by default.
Finally, this commit improves the processing needed for the swipe
animation between the columns.
Task ID: 1893137
closesodoo/odoo#40722
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
Reproduce the issue
- Install Projects
- Create a project
- Create a task with a deadline
The deadline format is correct in the form view but not in the
kanban view.
Cause
In the kanban view, there is some code applied on the `date_deadline`
field to add a class when the deadline is near.
As it uses a `span` with a `t-esc`, the only way to get the date
is to do `record.date_deadline.raw_value` which return the raw
value of the datetime object (a big string with all the infos).
This commit creates a char field for the formatted date and uses it
only for the display.
OPW-2122928
closesodoo/odoo#40707
Related: odoo/enterprise#6832
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
We want to allow different approvals for allocations and leaves of a same type.
e.g. In case of compensation days, a manager would approve the
allocation request, but would later not approve leave requests.
Specification
=============
Allocation modes
----------------
No change here except renames.
1. No limit (employee doesn't need an allocation to request a leave)
2. Allow employee requests
3. Fixed by Time Off Officer
Allocation approval
-------------------
A radio field to choose the approval mechanism
appears if the employee is allowed to request an allocation.
The following approval modes are possible:
1. Time Off Officer
2. Employee's Time Off Manager (leave_responsible_id)
3. Employee's Time Off Manager and Time Off Officer
These options are the same as leave approval options
(except the missing "No Validation").
If option 1 or 2 is selected, a o2m field should
allow to select which Time Off Officer is responsible
for approving those allocations.
Allocation approval policy is the same as the leave approval policy.
Task id: 1936742
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#35446
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
We are initializing over the limit to make sure we will compute it at least once.
If the target goal is set to 0, we are facing a division by zero error when
displaying the gamification goal just after initialization.
closesodoo/odoo#40735
X-original-commit: 24546e7c4cac61efea8d3f9e558518a55ef9acd2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do not update the date_planned of section/note purchase lines when
writing on the order date_planned. Otherwise the SQL constraint
ensuring display lines have no other data blocks the changes.
Fixes#40741closesodoo/odoo#40747
X-original-commit: f3ebab6eb52e3dc8be1f030aecfff348a22f7e09
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If the user put more than 200 emojis, we didn't replace emoji with
image. But due to a typo in the code, this mechanism broke the
discuss application.
closesodoo/odoo#40734
X-original-commit: 0877cb6c84c768bd9fad46fa6f959635bb2353a5
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
For each leave, a responsible is found to assign him activities.
For 'employee' leaves, a complex (and always changing) policy is
implemented.
This policy should not be applied for other types of leaves.
e.g. department, company, category.
For those type of leave, the current user should be responsible
for the approval.
Also, why was the default responsible the super user?
It was creating activities for an inactive user, hence no one
was notified to approve the leave.
Better to fallback on the current user.
Purpose
=======
We want to allow different approvals for allocations and leaves of a same type.
e.g. In case of compensation days, a manager would approve the
allocation request, but would later not approve leave requests.
Specification
=============
Allocation modes
----------------
No change here except renames.
1. No limit (employee doesn't need an allocation to request a leave)
2. Allow employee requests
3. Fixed by Time Off Officer
Allocation approval
-------------------
A radio field to choose the approval mechanism
appears if the employee is allowed to request an allocation.
The following approval modes are possible:
1. Time Off Officer
2. Employee's Time Off Manager (leave_responsible_id)
3. Employee's Time Off Manager and Time Off Officer
These options are the same as leave approval options
(except the missing "No Validation").
If option 1 or 2 is selected, a o2m field should
allow to select which Time Off Officer is responsible
for approving those allocations.
Allocation approval policy is the same as the leave approval policy.
Task id: 1936742
Access rights based on task 1950998
Install Accounting, go to Configuration > Follow-up Levels. Create a new
Follow-Up Action with low due days just to make testing easier and "Join
open invoices" enabled. Go to Customers>"Follow-up Reports", select a
follow up report with action "test", click on "Send Email"
The email will be sent, without attachments. There should be a number of
attachments equal to the number of due invoices, but for security reason
the attachments are filtered in the message post processing phase.
Changing security check to avoid filtering legitimate material.
opw-2116803
closesodoo/odoo#40726
X-original-commit: 6258c7eba905ee0d9591573dc8b0c90e6dc7111e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
'Send' button meant to send Italian e-invoices are shown
for invoices belonging to non-Italian companies as well.
Since the invoices' are being sent on validating the
invoice itself, Send button means less business here.
Hence removed it.
opw-1945836
closes#31470closesodoo/odoo#40736
X-original-commit: 633b931d4565b7e81ef69f6554a0a69b002b78e3
Signed-off-by: Josse Colpaert <jco@openerp.com>
An UBL invoice can contain several `AdditionalDocumentReference`, some
of them without `Attachment`. For example:
```
<cac:AdditionalDocumentReference>
<cbc:ID>UBL.BE</cbc:ID>
<cbc:DocumentDescription>BOB50 6.07.0</cbc:DocumentDescription>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
<cbc:ID>Facture N°19090118 - 30-09-2019.pdf</cbc:ID>
<cbc:DocumentDescription>CommercialInvoice</cbc:DocumentDescription>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject filename="Facture.pdf" mimeCode="application/pdf">JVBERi0xLjMK...
...
```
In this case, a crash occurs since:
```
element.xpath('cac:Attachment//cbc:EmbeddedDocumentBinaryObject', namespaces=namespaces)
```
is an empty list.
To avoid this, we loop on all elements and generate all PDFs.
opw-2128083
closesodoo/odoo#40721
X-original-commit: 2174e4066c5c8f87ed45aa564c184d1ce7063758
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
This fix makes no sense because it exposes some private data to
portal users. Fortunately it was only introduced in the master branch.
closesodoo/odoo#40710
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This merge adds a section to distinguish the certification badges from the
other badges users may obtain in eLearning. Certification badges are available
on the ranks page, linked to a running survey. Clicking on them directly
redirects into the linked course.
Other commits in this merge include
* renaming a category field on challenge to challenge_category to ease
its finding in code;
* renaming some statistics fields on badge model to ease its understanding;
* various usability improvements and fixes;
Task ID : 1961053
PR #32594
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a section to distinguish the certification badges from the
other badges users may obtain in eLearning. Certification badges are available
on the ranks page, linked to a running survey. Clicking on them directly
redirects into the linked course.
Task ID : 1961053
PR #32594
Purpose of this commit is to ensure challenge linked to surveys linked to
slides have ``slides`` category, while challenge linked to surveys not
linked to slides (if changing survey_id for example) have ``certification``
category.
With this patch challenges are correctly categorized, allowing to accurately
filter them based on their category.
Task ID : 1961053
PR #32594
In this commit we rename stat_count into granted_count, and stat_count_distinct
into granted_users_count to reflect more what are those variables, aka count
of granted badges.
Task ID: 1961053
PR #32594
If a component is used in a production with another unit of measure
than it's one, the created stock move line could not convert the quantity
correctly.
If there is enough quantity in stock, the created move line takes the
quant uom but the quantity in the production ones.
ex: consume 1 dozen, the quantity on the stock move line is 1 unit
This commit always uses the wo line's UoM and quantity to create the
stock move line.
closesodoo/odoo#39222
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue: open a done production. Unlock it. Add a new raw stock move.
This action will called _compute_order_finished_lot_ids on the new
stock_move. This method uses
move.raw_material_production_id.move_finished_ids.
raw_material_production_id is available but not move_finished_ids. The
reason is move_finished_id is not loaded by the web client in the
production form view.
This commit added the one2many (invisible) in the view in order to
get all the information in the compute method.
This form is mostly used in the 'Cost Analisys report' (mrp_account_enterprise module)
and needed an update to better integrated with the report
Task : 2082448
Before this commit, The addition of new stock move lines in a
finished production via the unlock button did not impact the
traceability report. This was due to the fact that the new sml
has not been linked to the finished_lot_id.
This commit extend the flexible consumption. On the workorder form view.
It's now possible to add directly new workorder line with any product
(even one not in any BoM line). For those new wo line. A confirmed stock
move is create in the record_production step.
Task : 2082448
There is no unique constraint on the properties to avoid having two
properties for the same field, company and res_id.
Having two properties for the same field, company and res_id, leads to
inconsistencies through the code, as reading a company-dependent field
nondeterministically returns one of the available property value.
So now, before creating a property, we have to check that there is not
already a value for the field, company and res_id and write or create
depending on if it is already exists.
The properties of specific records already satisfy the constraint thanks
to the implementation of company-dependent fields that use the method
`set_multi`. We added a method `set_default` to set generic properties,
and its implementation does the right thing. It also simplifies the
code to set such properties, by the way.
closesodoo/odoo#40473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Before this commit, the field `next_serial_count` in stock.move, used to
know how many SN the user wants to generate, wasn't correctly set and
was always equals to 0.
closesodoo/odoo#40714
X-original-commit: 9a20896eddb6b98b569f4f83192ac876696baaa6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, when user creates a receipt for a product tracked by
serial number, using immediate transfer, the fields to generate and
assign SN was hidden.
The reason was the move is confirmed in this case, and those fields was
displayed only for partially available and assigned moves.
task-2123761
X-original-commit: 4f9b170e857509cf34e072051086a7e9590c330d
Before this commit, with a time range activated in a pivot view,
click on a non empty cell would not always give the right list of
records because of a bad action domain.
The reason is that the headers domain or comparisonDomain were
not always set when appropriate:
- for the headers 'Total', the corresponding group obtained
by read_group does not contain the key __domain. For that
reason both the key domain and comparisonDomain were left
undefined.
- for headers that correspond to groups not present in the two
periods compared, one of the key was left undefined.
With the present commit, we correctly set the domain and
comparisonDomain keys everytime they are useful.
closesodoo/odoo#40713
X-original-commit: 2f89820faa5966b8321d6681e9745a4e938e2bec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit set date field as a date and set it on the lower
right corner.
task-id:1970451
closesodoo/odoo#32968
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
Currently, it is only possible to have 1 level of sub-tasks per task.
The user may want several levels of granurality.
Specifications
==============
Allow having multi levels of sub-tasks
- Move the parent_id field out of the debug mode and display it above the
Deadline field
- Remove the 'parent task' stat button
- Add the parent_id field to the project.task optional list view
- Display the sub-tasks stat button on sub-tasks
- The 'sub-tasks' stat button should only count/display tasks from the
first level of sub-tasks
- The name of the sub-task should be
parent task: sub task level 1: sub task level 2: sub task level 3...
- The sub-task should be created in the sub-task project set on the
parent task's project
- The subtask_planned_hours and the subtask_effective_hours fields should
take into account the planned hours of all sub-level tasks
TaskID: 2107078
Before this commit, calling gengo_authentication (executed from the
cron _send_translation_terms) returns an error when the python library
gengo is not found on the system.
If tried to request a synchronisation, got an error "NameError: name
'Gengo' is not defined"
Gengo variable was undefined as no imported.
closesodoo/odoo#40686
X-original-commit: 675b355954522caf7d72ab20cc431d19c5a05a8f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
No justification, commit message not linked to the diff.
If there is an issue in the line_number extraction it must be
investigated.
I suspect an outdated polib version.
closesodoo/odoo#40684
X-original-commit: 0f92dae8eb76a47326bd2bb8924df8fa09645145
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In case the Stripe API call fails, an Internal Server Error page is
displayed to the user, which is not user friendly.
opw-2126196
closesodoo/odoo#40678
X-original-commit: 95a452f6d928de2e8532027893a353167ffdd389
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Conditional expressions were already parsed, but there was no support
for executing them (or stringifying them back though I'm not sure when
that's used).
closesodoo/odoo#40502
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Add a bunch of timesheets for the 2 main demo projects in the project module
+ for one of the billable projects in sale_timesheet
closesodoo/odoo#40280
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Make some fields editable in multi edit.
Some onchange are tranformed in compute fields.
id=2078674
closesodoo/odoo#39711
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* we can just get the variable names once for the entire expression,
no need to bother doing it bit by bit
* avoid blowing up when the domain contains computations *around*
segments.
closesodoo/odoo#40642
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When a calendar event is created with a duration of for example 20
minutes, the end time appears as the start time + 19 minutes.
Because of the rounding of the duration (20 minutes = 0.333... hours),
the end time is incorrectly set (xx:19:59.998...) then displayed. Since
the duration can only be set by the minute, we round it before computing
the end time.
opw-2122853
closesodoo/odoo#40655
X-original-commit: f6ae9f0aea5a250cbff6734de8a43a1b741394a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A deadlock can occur between threads when concurrent requests
acquire the registry lock and conflicting database-level locks
in different orders. The database won't be able to detect and
break the deadlock because it involves an external, Python-level
lock. This situation is more likely to occur during module
installations [1].
If the server is started with the `limit_time_real` option,
it should be able to abort the deadlocked requests after the
timeout, and restart. However that could not work because
the recovery initiated by `reload()` is blocked at the end
of the `stop()` method, as it cannot acquire the registry
lock either, necessary for `Registry.delete_all()`.
Since that deletion step is in fact not necessary, it can
be skipped, avoiding the deadlock entirely.
Indeed there's no real reason anymore to delete the DB's
registry upon shutdown. This was introduced for 7.0 by
b5daffc115, in order to perform
other cleanups (including cron agent threads). These other
cleanups are not necessary anymore, and when the stop()
method of the ThreadedServer completes, the next step is
either a restart of the whole process (via execve() through
_reexec()), or a full process exit. Keeping the registry in
memory for a few cycles until this happens makes no difference.
When such a deadlock occurs, it's always possible to manually
kill the server with 2 `kill` commands, or 1 `kill -9`.
~~~~~~~~~~~~~~~~~~~~~~
[1] Reproduction info:
The following deadlock was observed in Odoo threaded server mode:
1. incoming request spawns a new thread A
A starts a transaction and does a "SELECT ... FROM res_users ..."
getting an ACCESS SHARE lock on the table
2. incoming request spawns a new thread B
B is a request that calls `button_immediate_install`, that will
install new modules and alter the res_users table.
3. B takes and holds the registry lock and executes "ALTER TABLE
res_users ...", that waits to get the ACCESS EXCLUSIVE lock on the
table until A's transaction releases the ACCESS SHARE lock.
4. A continues code execution and reaches a .sudo() call, it tries to
create a new environment. The creation of the new environment
requires to wait for the registry's lock to be release but it's held
by B.
-> A waits for B's registry lock to be released
-> B waits for A's ACCESS SHARE lock to be released
-> Deadlock that can't be broken except by force-killing the server
closesodoo/odoo#40664
X-original-commit: 9e67525418b3b0a48a796044ef24b227946ceb8f
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Since Odoo V13, ES6 is supported and we therefore do not support IE 11
anymore.
closesodoo/odoo#40661
X-original-commit: 9071a25394aa7a1749dc497fccea095bc8261181
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Robin Heinz