Remove superfluous dash in `project.task name_get` and replace it with
nbsp to be able to split on that specific value in a similar manner as
before.
Closesodoo/odoo#74350
Task ID: 2596229
Related: odoo/enterprise#19916
Related: odoo/upgrade#2705
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this PR when you accessed a certification through one company and passed it, the certification pdf was under the name of another company.
opw-2577532
closesodoo/odoo#75669
X-original-commit: 9f4fafee95e1f621a0d0b3a8bd5da6d059fa20c6
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
- Channels
* "hash tag" avatar with different backgroud colors
* only private channels have lock thread icon
- DM groups
* "users" avatar with different background colors
* no thread icon
task-2584994
closesodoo/odoo#75653
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Two tests in owl_dialog_tests were not correctly added in the parent
module of owl_dialog_tests.
These orphaned tests will therefore be associated with the previous
Qunit.module("name") and it will use its beforeEach.
If the module used does a makeTestEnv in its beforeEach, then the
"remove tabindex on inactive dialog" test will cause
"Error: Cannot add 'xxx' in this registry: it already exists" errors
because the test call createWebClient that does a second makeTestEnv.
closesodoo/odoo#75696
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Strap yourself in, we're in for a ride:
The module sale_stock_margin overrides
SaleOrderLine._compute_purchase_price and adds some extra dependencies,
the key dependency here is 'move_ids'.
The field move_ids is defined in sale_stock's override of
sale.order.line, however sale_stock is not a dependency of
sale_stock_margin, but since they implicitly share the same dependencies
and are both auto_install=True it is impossible to install
sale_stock_margin without having sale_stock be automatically installed.
However, since sale_stock_margin does not explicitly depend on
sale_stock, if one were to uninstall sale_stock without uninstalling
sale_stock_margin first, the registry would crash because
sale_stock_margin's override of _compute_purchase_price would depend
on a field that no longer exists (move_ids).
This commit changes sale_stock_margin's dependency graph to explicitly
depend on `sale_stock`, this in turn means we can forego the
`stock_account` dependency since it's an explicit dependency of
`sale_stock`.
closesodoo/odoo#75693
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When we want to open a quotation from the mobile view, we are
redirected to the POS Orders instead of the sale order.
This is because we are calling the wrong owl component.
Part-of: odoo/odoo#75682
Before this commit if the Apply/Discard buttons of the background image
positioning overlay were drawn outside of the visible area the user was
unable to access them - and thus had to reload the editor page.
After this commit the viewport is always scrolled to the background
image positioning overlay, making it always usable.
Because the block is always scrolled into the view, the buttons can
always be positioned near the top border of the overlay.
task-2627710
closesodoo/odoo#75679
X-original-commit: a9c3997b4bde08ceb75cacef7eb6ebad3efa7f44
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this fix applied color combinations were shown on the style
option.
After this fix the style option is displayed as any other plain option.
task-2612755
closesodoo/odoo#75665
X-original-commit: 2327248b8f67f5312f5630bf64fe49a31e025a09
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
Now you can specify into the dynamic_filter_template the number of record to
use for desktop, mobile, and the number of record to fetch.
Some template have only sense to be shown with 1 record e.g. a full width.
Syntax:
Add on root element one or more of these attributes:
data-number-of-elements="2" -> number of record on Desktop
data-number-of-elements-sm="2" -> number of record on Mobile
data-number-of-elements-fetch="2" -> number of record to fetch
closesodoo/odoo#75662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When there is a connection failure (eg. server restart) while we are
polling adyen for payment status during the payment process, we would
show a connection error and when clicking on retry, we would do a new
payment even if the first one was successful causing a double payment.
After dcb1e2b48, the retry after failure should just continue the
polling as if there was no connection failure, so for example:
- order 1: pay with adyen => connection failure during payment
- order 1: retry => payment successful
But in this particular case:
- order 1: pay with adyen => connection failure during payment
- order 1: close adyen payment line and pay with another payment method
- order 2: pay with adyen => we will receive the response from order 1
With this changeset, we only continue the polling for adyen status if we
are retrying to pay the same order.
opw-2587625
closesodoo/odoo#75640
X-original-commit: f83d1b13a96f8df559918b5905b949009d2ece88
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When the bills linked to a vehicle are displayed, the creation date is not always relevant. Sometimes, the Invoice/Bill Date is more interesting.
To avoid confusion, "Date" is renamed "Creation Date" and the column "Invoice/Bill Date" is added between "Creation Date" and the "Number" (bill number) columns.
Summary of the changes:
On the bills tree view for a specific car:
- "Date" is renamed in "Creation Date"
- "Invoice/Bill Date" is added between the "Creation Date" and the "Number" columns, the default is optional:show
task-2629316
closesodoo/odoo#75582
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit makes some major changes in the Point of Sale module
when posting journal entries which allowed the following new features:
1. Show that the invoice generated is paid unlike before where invoice
doesn't appear to be paid (both in the pdf and in the backend).
2. User can create a 'Pay Later' payment method (created by default as
'Customer Account') to allow the customers to make credit in their
purchases.
3. An extension possibility where POS can settle customers dues.
The above is accomplished by doing the following:
1. Invoices are now reconciled to created account moves by POS using
the pos payments registered to the pos order. And this is done
right after the order is synced to the backend.
2. A new type of pos payment called 'pay_later' is introduced.
- When an order is invoiced and is paid with 'pay_later' payment,
the customer in the invoice will have `due` in his account which is
immediately reflected when the order is synced.
- When an order is not invoiced and is paid with 'pay_later' payment,
the customer's 'due' reflects when the session is closed.
3. When the session is closed, POS payments from cash payment methods
are moved to the default account of the cash journal specified in the
payment method via creation of `account.bank.statement.line`s. (This is
already the case but it is mentioned this is for the purpose of
transparency.)
4. As for the bank pos payments, `account.payment` records are created
to move the payments to the specified `outstanding_account_id` in the
pos payment method. The `account.payment` records are written the bank
journal specified in the payment method.
5. As for the `pay_later` payments, we keep the behavior when no
journal is specified in the payment method where payments become
receivables to the customer who made the payments.
Other notable changes:
- The default POSS journal is changed to have 'general' type in order
to able to view the journal entries written in it.
- `pos.payment.method` can now be categorized as 'cash', 'bank' or 'pay_later'.
- `account_default_pos_receivable_account_id` can now be configured from
the Point of Sale general settings.
- `pos_invoice_report` is removed in favor of `account.account_invoices`
- disallow creating new payment method from `pos.config` form
- 'Journal Items' button in the `pos.session` form are now always visible.
- This allows seeing the list of invoices (and their payment moves)
to be accessible thru this button.
See test cases from the following spreadsheet:
https://docs.google.com/spreadsheets/d/1mt2jRSDU7OONPBFjwyTcnhRjITQI8rGMLLQA5K3fAjo/edit?usp=sharing
Part-of: odoo/odoo#74870
Purpose of the commit is to do the generic improvement for the
timesheets app.
So in this commit, done the following changes:
- added the "Timesheet Entries" report for the project.task object in project app.
- added the "Minimal duration and rounding applied when using the timer"
description for 'round timesheets' and rename 'round timesheets' to 'Time
Rounding' in the setting of the timesheets app.
- added the kanban view for the "reporting" menus in the timesheets app.
- change the 'x Timesheets' stat button into 'x Hours recorded' and icon to
'fa-clock-o' in invoice form view.
- rename 'round timesheets' to 'Time Rounding' in
setting.
closesodoo/odoo#71590
Taskid: 2459783
Related: odoo/enterprise#18668
Related: odoo/upgrade#2525
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In the backorder process the operation are done in this order:
1. If the MO has workorders then set the remaining quantity as quantity
producing
2. Confirm the moves
However the system do not expect qty done on draft moves for a lot
of operations.
This commit inverse the order to allow some buisness logique to work
(e.g the analytic accounting)
opw-2469742
closesodoo/odoo#68708
Related: odoo/enterprise#18594
Related: odoo/upgrade#2739
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add analytic accounting for MO.
Post expense entries for:
1. raw material cost (change with consumed)
2. work center cost (change with real duration on work order)
Task-2469742
PR #68708
before this commit:
undefined data was keep coming in line graph, when timesheets were installed.
after this commit:
fixed the demo data from which this problem araises.
closesodoo/odoo#73313
Taskid: 2531430
Related: odoo/enterprise#19471
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In this commit done following changes:
- add name_get to account_analytic_line model.
- changes in form view of timesheets menu
- hide company_id and amount field.
- move date field above unit_amount field.
- move employee_id field above name field in all timesheet menu.
- add so_line field in timesheets menu and move employee_id before
date in all timesheet menu when so_line is available.
- add so_line field in list view of timesheets menu as optional hide.
- add so_line field to kanban view after name field and change
o_kanban_record_top height 50 to 51 to show it properly.
- add a search for sale order item(so_line) and remove a search for
billable type(timesheet_invoice_type).
- remove filters Billable and Non Billable.
- add group_by for so_line and timesheet_invoice_id fields.
closesodoo/odoo#72979
Taskid: 2510313
Related: odoo/enterprise#19372
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Adds the employee tags as an optional field in the employee list view
as well as in the search view.
Closes: odoo/odoo#75480
Task ID: 2630604
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Add some "optional=show" in MO and WO, to have the possibility to hide some columns
Change the color of the state in MO list (we need to have the state draft in another color than grey)
--- Links ---
The PR: https://github.com/odoo/odoo/pull/75334
Task related: 2615395
closesodoo/odoo#75334
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Issue: When computing the landed cost for a transfer with quantity 0,
the validation of the LC wasn't working since there was a quantity 0
Steps to reproduce :
1) Create a PO for some items
2) Confirm, validate the delivery
3) Edit and unlock the delivery, set one quantity to 0, save
4) Create a landed cost for that transfer
5) Compute it
6) Validate -> Traceback
Why is that a bug:
There should not be a traceback, this is caused by trying to validate
a landed cost for a product where there is no quantity, if there is no
quantity, it should be part of the landed cost computation
opw-2599799
closesodoo/odoo#75565
X-original-commit: 800433bde03a36ead40a78bc6d53cbb95c24f97b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
Issue: In work centers with a capacity different than 1, the expected
duration was wrongly computed
Steps to reproduce :
1) Install Manufacture, enable Work Centers in Settings
2) Create a Work Center, Capacity = 2
3) Create a Product, with Manufacture as route
4) Create a Bill of Material :
Add any component
Add a operation line :
Work Center = created at 2)
Duration Computation = based on tracked time last 1 WO
5) Create a Manufacturing Order for the product 3), confirm
6) Set the real duration to 00:10, mark as done
7) Check the BoM Structure & Cost of the BoM 4)
-> Operations is 00:20
Why is that a bug:
To compute the expected duration, in mrp_workorder.py L691 we already
take into consideration the capacity of the work center.
When computing the time_cycle, we must give a time_cycle for 1 product
made with capacity 1, so we must first normalize the qty_produced fetch
from the DB to make like if we only produced the quantity once but in
the same amount of time
Side-Note: This also solves an issue with the Duration Computation based
on tracked time. The `limit` keyword was applied after the `group by`
so we effectively grouped all the operation_ids together, summing
their quantities and then limiting on the different operation_ids
opw-2562983
closesodoo/odoo#75557
X-original-commit: c78a25f92716bd6014de381c34f3bc268d1528ae
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
Some footer and header templates, introduced in [1] were using snippet
classes without the snippet data attribute. Therefore, they were not
using the snippets versioning system.
For example, the template_footer_descriptive was using an outdated
version of the s_title snippet, when a V001 css version had already been
introduced by [2].
[1]: 34ed29cbac80180982c9acc86c1412433bb88919
[2]: f34d7f4fab
task-2212216
closesodoo/odoo#75670
X-original-commit: bc4091e3049257a4517e556d51b2ed8e06e2095e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- The UI was updated twice (first to remove the overlay then to reselect
a surrounding snippet) -> that could be done in one operation.
- The UI update was not fully awaited.
- Add some inline comments to make the code more readable.
Note: this could be backported if the need ever arise.
Part of https://github.com/odoo/odoo/pull/74941
Part-of: odoo/odoo#74941
The editor was updated to handle a TODO but the TODO comment was not
removed. Originally, I wanted this commit to handle all TODO comments
around that code but failed to find the time -> at least this fixes the
comments...
Part of https://github.com/odoo/odoo/pull/74941
Part-of: odoo/odoo#74941
`isOpen` is only written during mounted but it might happen that the discuss
record is not yet created when the component is mounted.
task-2632702
closesodoo/odoo#75655
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Allow to group records by many2many fields.
Use case: turn the user_id m2o field on project.task into a user_ids m2m field
in order to assign multiple collaborators on a task
SPECIFICATION
Add many2many fields to the 'list of groupable fields'.
When grouping a set of records by a many2many, records linked to multiple
records of the comodel will essentially be in multiple 'groups' (even though
those are not really 'groups' anymore).
There will also be a "null" group, for records that have an empty value of the
many2many, like "unassigned" records.
Example: grouping a project.task linked to 10 res.users by the user_ids
many2many field, the project.task will be 'rendered/considered/displayed' 10
times, once per res.users.
Kind of like if we grouped the m2m relation table instead.
When grouping by a m2m field:
- listview
editing an instance of a record also updates each other instance(if any)
- the same goes when scheduling an activity, etc.
disable deletion
- the risk here is that the user might expected that this will 'unlike'
the record from a specific record of the many2many field
disable archive/unarchive
- kanban
disable drag&drop between groups
disable deletion
disable archive/unarchive
- searchview
display many2many fields custom groupby dropdown
With this commit, we also support groupby many2many field in mockServer so that
test cases are written based on that.
task-2508608
closesodoo/odoo#74985
Related: odoo/enterprise#20192
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The value returned by the search_read in read_progress_bar when passing
a m2m field is a list of ids, which then read_progress_bar tries to use
in a dictionary, list is not a hashable type thus it crashes.
With this commit we convert the group_by_value from list to tuple,
which is hashable, if we're dealing with a many2many field.
task-2508608
Part-of: odoo/odoo#74985
Grouping by many2many has been added with PR odoo/odoo#68958 (commit f4f570c3d6b403512d8523c74acd34d485f46af1)
However the display names are not resolved resulting in the grouping
displaying the actual id of the records.
This also breaks some features such as `read_groups` which expect the
group by data to contain a tuple (id, x) instead of just the id, this
commit adds name resolving on many2many group bys.
Task ID: 2398734
Part-of: odoo/odoo#74985
Purpose:
=======
This commit adds the project sharing feature. This feature consists to
share the backend views about project.task to portal users.
About the access rights:
- The project manager can share a project with project sharing feature.
To do this, he need to give access to portal users that we want their access in project sharing views.
He can choose between 2 differents accesses:
1. **Readonly**: The use has access to the classic portal views (on which he can post messages, and have a readonly access rights to the related fields)
2. **Edit**: the portal with this access right will can edit some fields of `project.task` model.
The difference between the classic backend views and the project sharing
views is in the project sharing views, we list the fields that the user
can read/write, so the portal users can see only the fields in
our list.
Moreover, the actions and the contextual menu (actions dropdown) are not
available in the project sharing views and the stat buttons are visible
but the click on these buttons are disabled.
Implementation details:
======================
- add `allow_project_sharing` option in project form view.
- create the webclient and routes.
- create own qweb bundle.
- add project sharing views.
- use the session to define the action and active_id
- create public fields for project sharing: in this step, we lists all field
names of the `project.task` model that we want to display for the
portal user. Two lists are created, one for only readable field names
and the other one for the writable field names.
Moreover, two properties are defined in the `project.task` model to use the
both lists.
- use `access_token` and check model in project sharing route: in this
step we check if the model is `project.project` and the `access_token`
is the one set in the project since we have the id of the project in the
params url.
- protect ORM methods: to avoid the portal user has accessed to too much
fields that he can, we have to check if all asked fields are in
the readable fields, if all fields are available for these users than we do the
method, otherwise we raise an `AccessError` exception.
- allow only `GET` method to enter project_sharing routes: the
`/my/project/<int:project_id>/project_sharing` route must only be
called with a `GET` method because this route is only used to have the template
to render the project sharing webclient.
- redirect the link in one of the sharing wizards to project sharing views if the portal user has an access
to the shared project and if the shared project has the Project Sharing feature enabled.
- only load `project.task` views for project sharing.
- remove longpolling in the project sharing.
- disable click on avatar to open the chat with the user or open the hr.employee form because these features are not authorize in the project sharing.
- remove the contextual action menu in the project sharing views
- add the chatter in the `project.task` form for the portal user with at least 'comment' access.
This user could send message and see the public message like portal chatter.
- replace the basic portal views when the portal user selects project in `/my/projects` by the project sharing views if the `allow_project_sharing` is enabled for this project and if the portal user can access to the project sharing views of this project.
Why did we implement this feature in this way ?
====================================
We thought to create a `project.task.portal` model. This model had contained all fields that the portal user can read and edit (`readonly=True` if the portal user can just read the field).
We had 2 possibilities for this solution:
1. link this model with `project.task` either with inherits attribute in `project.task` or by creating a many2one field in the project.task.
The problem with this solution is with `inherits`, we just copy all fields in `project.task` and not method, so we need to duplicate methods used in both models. Moreover, with `inherits` possbility, we have to create all records even if the Project Sharing feature is not used. If we took the other possibility (that is, create the Many2one field in `project.task` model) asks to create records when the `allow_project_sharing=True` in a project and also unlink/archive records when the Project Sharing feature is disabled in a project. The process is harder each time, the user enables/disables the feature. That's why we didn't do this solution.
2. the new model contains a sql view and we use the related field to create/edit tasks in project sharing views.
We don't do this solution because it was a big change and increase the complexity. Moreover, if the sql view gives all tasks of shared projects, we could have a security issue because the portal user could have access to the tasks of shared project in which he didn't have any access.
Another solution that we thought before doing this feature was to create the kanban view in portal. We didn't do that because:
1. the render of this view will not be the same than the one in `/web`,
2. we didn't want to duplicate the kanban view,
3. we need to allow the portal to create/edit task.
task-2379518
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#73341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit fixes a behavior when we send a batch of mailings
with no recipients.
When there is no recipients passed down, each mailing should
use it's own recipients and not the recipients of the first mailing.
closesodoo/odoo#75652
X-original-commit: 88d74fde5ce1ec70a88679429fda02180ce7fa81
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, this route displayed the portal form view of the
project. This view does not seem useful for the external user and prefer
directly see the tasks of this project.
This commit replaces the portal form view of the project by the tasks
list containing in the project. Moreover, another route has been added
to allow the external user to go to the portal form view of the task
selected in ths list.
This route is called '/my/project/<project_id>/task/<task_id>'.
We decide to replace the content of the route because we want to allow
the public user to access to the tasks list of the project with the
access_token of the project. Also, with this same token, the public
could access to the form view of the selected task and send a message if
he needs.
task-2379518
closes#73341
Before this commit, the project manager could edit the collaborator
records. That is, he could change the shared project or the
collaborator.
This commit allows the user to only see or remove the collaborators for
a shared project. If the user wants to add some new collaborators, he
has to use the project share wizard.
task-2379518
closes#73341
Before this commit, the project sharing feature is enabled by default
when the Project app is installed but the user could never use the
feature and thus we add more access rights to portal user for nothing.
To avoid this, this commit removes by default all additional access
rights given by project sharing feature and adds this access rights only
when a collaborator is added.
If the user removes all collaborators for all projects then we need
to disable the feature. That is, we will remove the access rights and
ir.rule records added.
So, the feature will not really disable but we remove the additionnal
access rights and ir.rule records added with this feature.
task-2379518
closes#73341
This reverts commit fc7778f8c512202dc3361d6b87be8c28b299c3c8 because of
a change in the spec.
The access mode are removed and replaced by this access mode for portal
user:
- read: the user goes to the classic portal view
- edit: the user is added as collaborator of the shared project and can
access to project sharing views.
To do this, the portal share is inherited by the project share wizard.
This new wizard can be open to share in readonly and open to share in
edit mode via 2 buttons in the form view of the shared project.
A new stat button is added to form view of project to see the
collaborators of this project. That is, the ones can access to the
project sharing views. The project manager will can remove or also add
new collaborators via the views in this stat button.
task-2379518
closes#73341
William Braeckman