From task stat button from SO form view, it
is relevant to see the task of the SO only.
So, we add a filter to do so. AS the kanban
task use a read_group, it is required to store
the sale_order_id field on task.
The code of the project overview is split to be used when only
timesheet is installed (no forecast). The table part only
display column for timesheeted time per month.
When forecast is installed and activated, other columns
comes to complete this table.
This commit also makes visible SO line having no timesheet
linked in project overview.
When selling a project from a sale order, the SO line
creates the project. When we create a task in that
kind of project, by default, the task will be linked
to the SO line of its project.
However, for the SO line field to be visible on the
task form view, the customer must be set. This commit
set the customer from the SO line when changing
the project (billable project only).
Selling product creating project can now be based
on project template. When setting a project template
on product, this will copy the project (like a duplicate)
and replace its customer, ... with information from the
SO line, on SO confirmation.
There is only one project without template per SO, and
one project per template per SO (so 2 SO lines with the
same project template on their product will only create
one project with this template).
When confirming a SO, only one project will be created, even if
some so lines would create a project. Only the first line will
create the project, the other will not be linked to its.
`project_id` field is added on so line, to keep track of the
generated project, as already done for the task.
The '_timesheet_service_generation' method has been rewritten
to be execute in batch and improve performance and prefetching.
On SO confirmation, no message are now post in chatter to avoid
having one message per so line that should have created a task.
A message is only posted when user manually add SO lines on
confirmed SO.
Now that an analytic account can be linked
to several projects, you might want to change
the analytic on the SO.
Before this commit, the user was allow to create
an analytic account on a confirmed SO but not
modify it. This was usefull when you wanted to
reinvoice an expense on a SO without AA set.
This is now solved (AA is automatically created
when validated expense).
Now, we want to allow set manually the AA before
confirming SO to match the one of potential
projects.
This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.
This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.
This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).
The project overview is kind of badly design. This
commit does not solve all the issue but tries to make
it simpler and more efficient:
- Does not depends on AAL anymore: the overview search
is now about projects. You can see the overview of multiple
projects. Even when no timesheet are encoded, the plan will
not be empty.
- "Time by people" displays each employee assigned to task,
even if no timesheet are recorded.
- Code now use reporting view to keep consistency and simple
code in overview controller.
The cost of an employee should be in hr_timesheet for a long time, to
allow user to track time on project/task: hours spent and their cost.
This commit simply moves fields and related views. It also moves the
'postprocess' method from sale_timesheet to hr_timesheet since this
method is responsible to set the amount (cost) on AAL.
User can now track their time and cost, without having sale_timesheet
installed.
The project of a SO will not be used anymore, as we planned
to have a sale order creating multiple projects.
The concept of 'only project from SO' does not make sense.
This commit provide a real reporting tool
for project profitability: graph and pivot
views.
You can now have a look at cost and revenues
per project, so line, product, see which
project manager brings the more money, which
project costs many human time, ...
The project overview is based on this report
analysis to be consistent.
However, a change of computation for 'amount
invoiced' is introduced: we now based the amount
on the price_reduce of the SO line, and not from
the invoice lines. Also, once a draft invoice is
generated, the quantity is considered as invoiced
at the price of the SO line (no matter is extra
discount happens when validating invoices).
- Redesign all mimetype icons
- use SVG to reduce file size and improve rendering quality.
- Add a data attribute to attachments to detect the file extension (in somes
cases just mimetype is not accurate)
In some case, (many JS like runbot with all modules), the onload event was
binded after that the image was loaded. So the JS code that make the zoom
conditionnal was not executed.
Now we apply the function on all images already loaded, or that will is loading
Courtesy of @ged-odoo for help and review
An empty div `o_attachment_preview` is added in expense and vendor bills form
views. It will be used as a container to preview the attachment.
The actual behaviour will be implemented in another commit.
Task 40663
Purpose
========
The links on the project kanban cards are not always at the same place : https://drive.google.com/file/d/1aONUYkZerqqD7fSVmgozRScgLKR-QHtA/view
============
Specification
============
I get rid of the flex element to allow the placing of links using width
attribute. Create the .o_project_timesheet_box class to assure that the
timesheet/overview link is always placed in the middle.
I also deleted the needaction_count button to avoid breaking the display.
Task: 1817850
Before this rev:
* Take 2 domains that contain at least two leaves, and at least one of
them must use the implicit `&` operator
e.g.:
d1 = [('so_line', 'in', [91]), ('amount', '<=', 0.0)]
d2 = ['&', ('so_line', 'in', []), ('project_id', '!=', False)]
* Perform osv.expression.OR() between both domains
Expected result:
d3 = ['|', d1, d2]
Actual result (after normalization):
d3 = ['&', '|', d1, d2]
This is because, since the `&` is implicit for the first domain, when we
OR it, we give it an explicit `|` operator, so when we pass this domain
through the normalize_domain function, d1 no longer contains an implicit
`&` operator but instead the implicit operator is the one between d1 and
d2, therefore giving us a completely wrong domain.
The `combine` function states that it only accepts normalized domains,
however neither the OR nor AND functions do, this leads to a lot of
developers putting non-normalized domains into these functions, and
there's no error checking or anything that obviously indicates that the
domain is incorrect, so we might as well normalize all domains being
passed since it's already pretty optimized.
Chat window having higher z-index value then attachment preview model and in the
mobile chat windows are covers whole screen so attachment preview is hidden behind
chat window. so increasing preview model's z-index by 1 will fix the issue.
(PR #24065)
The read_group method was recently modified to allow more flexibility.
With this commit, we add the possibility of aggregating many2one fields.
These fields can be aggregating by counting the number of distinct IDs,
directly in postgres.
Also, note that we had to modify the mock server to implement the
corresponding functionality.
For x2many relational fields(of type kanban), we shoud be able to set custom label for
'Create / Add' button by adding 'create_text' node option on particual field from xml.
Right now, 'create_text' is only handled for many2many fields, preventing users to set
custom label for one2many fields.
This commit allows users to set Create Button label for both m2m and o2m fields.
This commit fixes two issues with discuss tests (JS):
1. Improved mocked `message_fetch` rpc
Some tests were incorrectly mocking the `message_fetch` rpc.
With this commit, the mock server correctly mock this route,
so that tests should simply pass the records as data, and the
mock server correctly handles this rpc.
2. Patch `_.debounce` and `_.throttle`
The test "older messages are loaded on scroll" failed with
Google Chrome right after destroying the widget discuss.
This is due to a debounced function that called its inner
function at this moment.
With this commit, any discuss test patch `_.debounce` and
`_.throttle` so that the inner functions are executed
immediately and synchronously.
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
This fix will be backported in v10.0 and v11.0 as soon as it has been
battle tested.
Also when there is both a docstring and directive-level content put
the docstring first. That seems to match what Sphinx's autodoc does
and looks less odd.
Possible future improvement: a parameter to suppress the docstring?
Possibly a way to reorder the non-docstring content (e.g. members
documentation)?
- Improve design
- LESS: use mixing and variables when possible, code formatting
- Solve a minor issue causing images to be not perfectly centered
- Improve visual feedbacks (tooltips, cursors, hover states...)
The read_group method (from the server) is implemented in the mock
server, to allow easy unit testing in javascript. However, the
behaviour was not exactly the same: a read_group call on a domain with
no records returns null for aggregates. But the mock implementation
returned a value of 0.
We fix this in this commit, to allow more precise testing of Odoo
javascript.
The state of the JS documentation was quite sad, not updated in a long
time. With this commit, we rework a lot of the JS doc. Most notably,
we add a section 'Javascript Cheatsheet' (help on some common
customization tasks) and rewrite the 'Javascript Reference' totally.
Note that the JS reference page also contains a reference on all field
widgets.
This work is just the beginning, it is probably not complete, but at
least we will have a foundation.
This wizard allows the stock users to replenish a product using the
routes applied to this product. A specific route can also be applied
to bypass the default route.
This replaces the "request procurement" wizard from v10, lost during the
stock refactoing.
Task ID: 47938
related to #22041
This commit allows to define a putaway strategy by product. Before
this commit, it was only possible to define a putaway strategy by
category.
We add a second one2many on the model 'product.putaway': the original
(fixed_location_ids) is used for the putaway per category, the new one
(product_location_ids) is used for the putway per product.
The two one2many are displayed on the putaway strategy and a domain on
the fields is used to filter the records between them. Inline tree view
add a required on the product_id on the one2many per product and a
required on category_id on the one2many per category.
If a putaway strategy per product AND per category match for a product,
the putaway per product takes precedence
This task also reword some tooltips.
We add some testcases to display the behaviour
- when a putaway per product is applied
- the conflict between a putaway per product and category
- the fallback to the category when nothing is found on the product
Task 23495
PR #20143
* don't use FS to do export
* update translations export dialog to fix outdated links (launchpad
& 6.1 translations doc)
Note: can't use ``TarFile.gettarinfo`` to create the TarInfo object
because it wants an actual file object with a ``name`` attribute and
possibly even an fd.
closes#22798
This merge replaces followers subscription code in order to be optimized
and perform less queries. This improvement is done in several steps :
* mail followers model has new low-level and optimized methods to compute
followers to create or update. It uses SQL queries to fetch data in a
single request;
* mail thread message_subscribe method is rewritten to use this new method.
Its API is also simplified and message_subscribe_user is removed to
simplify the whole subscription API;
* auto subscription is also rewritten. Fetching subtype data about parent /
child like project / task is done in a single query that prepares data.
It then uses new method to create followers;
Various addons are updated because of message_subscribe or auto subscription
change. Functionally behavior should stay the same as purpose is to be
equivalent in term of functional coverage.
Performance counters show this optimized code works well when dealing with
large set of followers to subscribe or update. Most tests perform better
of a few queries. Most complex ones involving (auto) subscription of several
followers perform way better. About 30% of query are saved in the three top
tests, aka between 80 and 90 queries with auto subscription of 10 followers.
On overall community runbot we have a gain of about 11K queries. As Odoo
data has few followers impact on runbot is probably less interesting than
impact on real-life use case.
Thanks to @rco-odoo for reviewing, and cheers !
Expense report has custom code to add people as followers. This code has
several issues, notably in some cases it could try to add several times
same people, leading to crash and issues.
As auto subscription has been cleaned let us clean the code in hr expense.
Using _message_auto_subscribe_followers it is now simpler to automatically
add follower to expense reports. It is not necessary to add hackish custom
code in create and write.
One change is done in this commit. Some people are set as follower after
record creation and not before. However this was necessary when tracking
messages were not correctly triggered or auto subscription done after
tracking. As process is now 1/ create 2/ auto subscribe 3/ tracking, messages
linked to tracking will be correctly push to recipients automatically added
as followers.
This commit refactors mail.thread message_auto_subscribe method. Purpose
of this method is to automatically subscribe people to documents in several
scenarios
* followers from an umbrella record to sub-records, like followers of project
added to tasks;
* responsible of documents, in addition to sending notifications to newly
added responsibles;
* some specific use case depending on some applications like managers
for expense reports;
New auto subscription now uses the recently introduced method optimized to
compute new or to-update followers. It is also rewritten so that overriding
it is easier. Indeed simply overriding _message_auto_subscribe_followers is
now sufficient to add new followers to a record, depending on some updated
values. It is also now possible to specify a template to use for some
specific notification, if requested.
Fetching auto-subscription data in subtype is also optimized. It is now done
in a single SQL query. All data related to parent (like project) and child
(like task) as well as default and internal-only data is prepared in a single
query and given back to auto subscription process. This allows to gain
queries in auto subscription based on subtype like project / task use case.
This commit has a great impact on performance counters. Complex use cases
involving tracking and responsible notifications gain about 30 queries which
is about 15% of their total query count.
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
Override of create in mail.thread now uses the recently introduced
_add_default_followers to add the record's creator in the followers.
It allows to save one query when creating new records. It means for simple
models we approach the bottom limit in term of generated queries which is
quite a good news.
This commit adds new methods to add or update followers to documents. Purpose
is to have new optimized methods that perform less queries. It is based on
experience and use cases of various addons in Odoo using it.
Technically two main methods are given on mail.followers model
* _add_followers: this method generates values required to create new
followers or update existing one. It takes several parameter controlling
how to deal with existing followers. This is used notably when auto
subscription should not erase existing subscriptions;
* _insert_followers: this method creates or updates followers for a given
set of documents. It uses result from _add_followers;
Performance gain come from the use of a SQL query to fetch followers data
as well as less use of record sets. Code can be more low-level in some
places. Purpose is to avoid browse and prefetch and just fetch data once
and use it in various computation.
New implementation is equivalent to the old one. It offers more flexibility
as caller can either receive values for followers or directly have records
created and updated. Various parameter allow to tune computation depending
on each specific call to the new follower methods.
Future commits will gradually replace the use of old _add_follower_command
by the new methods. Purpose is to replace them one by one in order to see
the gain in term of performance one replacement at a time.
Move zoom next the original picture
Disable it if same img and max size with ratio < 1.5
Allow to enable zoom automatically
...
Task-33499
Co-authored-by: Jérémy Kersten <jke@odoo.com>
In the normal course of saving-action, readonly fields are stripped
out when sending data to the server. The SSF would reuse the same code
when "saving" O2M lines to the parent record however that is not
correct and would lead to misbehaving views as readonly (non-stored)
fields used as "transients" (storing data within the extent of a
record's edition session) would not behave properly.
Fix by overriding the O2M Form's save so that readonly fields are
kept and stored in the parent record.
Closes#23620
This rev. extracts two rendering parameters for the groups
corresponding to the default col value to apply (for inner and for
outer groups). This allows to easily override those default values
in extentions of the FormRenderer (for instance, in the renderer
of the new Dashboard view).
This rev. refactors the way the view's arch is parsed in BasicView,
so that it can be extended specifications of the BasicView to
handle other tagnames that 'field' (which is basically the only
one handled in BasicView).
This rev. extracts the part of the rendering that renders outer
groups (i.e. groups that contain groups) in its own function. This
allows extentions of the FormRenderer to use it (for instance, the
renderer of the new Dashboard view).
This rev. introduces an option to doAction (keepSearchView). If set
to true, the searchView of the current action will be kept and used
by the new action (this only works if there is already an action
with a searchView, and if the new action is stacked over that one).
This is necessary for the new dashboard view.
A better solution would have been to export the state of the
existing searchView, and import it to the new one, but the current
implementation of the searchView doesn't allow to do that easily.
This will be done as soon as the searchView will be rewrote.
This rev. allows to add or remove filters to the SearchView from
the outside, and to make it display this new domain. This can be
used by views that trigger domain changes (e.g. this is the case
of the new DashboardView).
jem-odoo