PURPOSE
Purpose is to perform some cleaning in survey models: naming, ordering,
dead code [0]. As new features are about to land in survey, notably live
interactions [1] and new survey building [2] performing a pre cleaning
is necessary [3].
SPECIFICATIONS
This merge contains three commits doing
* code move;
* dead code removal;
* templates split to ease understanding and reading;
See sub commits for more details.
LINKS
[0] Related to Task ID 2144393 (surveys split / cleaning)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
[3] Task ID 2061901 (survey models cleaning and preparation)
PR #40623
Related: odoo/enterprise#6853
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
PURPOSE
Purpose is to perform some cleaning in survey models: naming, ordering,
dead code [0]. As new features are about to land in survey, notably live
interactions [1] and new survey building [2] performing a pre cleaning
is necessary [3].
SPECIFICATIONS
Remove dead code :
* split templates into 3 main files
* survey_templates: holding main templates when taking a survey;
* survey_templates_statistics: graph and statistics (results) of a survey;
* survey_templates_management: templates linked to corner cases and
error management (403, closed survey, ...) as well as tools and utility
templates;
* rename template ids to ease code understanding;
No functional changes should occur with this commit. It contains only
code move, not any change at all.
LINKS
[0] Related to Task ID 2144393 (surveys split / cleaning)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
[3] Task ID 2061901 (survey models cleaning and preparation)
PR #40623
PURPOSE
Purpose is to perform some cleaning in survey models: naming, ordering,
dead code [0]. As new features are about to land in survey, notably live
interactions [1] and new survey building [2] performing a pre cleaning
is necessary [3].
SPECIFICATIONS
Remove dead code :
* old code bits not used anymore since several code cleanings have
already been performed;
* use tools when possible instead of manually checking stuff like
email validation;
* clean unused imports;
No functional changes should occur with this commit. It contains only
code move, not any change at all.
LINKS
[0] Related to Task ID 2144393 (surveys split / cleaning)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
[3] Task ID 2061901 (survey models cleaning and preparation)
PR #40623
PURPOSE
Purpose is to perform some cleaning in survey models: naming, ordering,
dead code [0]. As new features are about to land in survey, notably live
interactions [1] and new survey building [2] performing a pre cleaning
is necessary [3].
SPECIFICATIONS
Code move main points
* move fields to have them grouped by main use;
* move methods to have them grouped by main purpose;
* reorganize some line breaks to ease reading files;
Globally this code move is done according to our famous guidelines.
No functional changes should occur with this commit. It contains only
code move, not any change at all.
LINKS
[0] Related to Task ID 2144393 (surveys split / cleaning)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
[3] Task ID 2061901 (survey models cleaning and preparation)
PR #40623
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>
Odoo's Mergebot