Currently default displayed sales team in dashboard are the one current
user is member of. However as an user can be member of only one sales team
it is not very easy to manipulate.
This commit improves that behavior by adding a favorite mechanism. Users
can favorite several sales team. Those are displayed in the dashboard
allowing users to decide which sales team to display independently of
being a member of the team or not.
Dashboard now also display a search bar in order to be able to change the
default behavior and choose other filters if necessary.
A security rule is updated as salesmen should be able to read several
sales team from now on.
This commit modifies the way field widgets can specify the fields to fetch.
Before this commit, a key `fetchSubFields` was used to fetch the `display_name`
and the `color` in the many2manytag, but this behavior wasn't generic.
A new key `fieldsToFetch` has now been introduced ; it should contain the
definition of all fields to fetch.
Introspection attributes on function and methods were originally
prefixed with func_ or im_ e.g. im_class or func_name. For coherence with the
rest of the data model, Python 3 added dunder attributes (__func__,
__code__) and removed the old style, the dunder attributes were
backported to Python 2.6.
Use dunder attributes everywhere we're currently using func_* or im_*
attributes.
Fixers:
lib2to3.fixes.fix_funcattrs
lib2to3.fixes.fix_methodattrs
#8530
Most of the type aliases in the types modules are remnants from when
the corresponding builtins were just conversion functions and not
proper types (before type and class unification).
Python 3 removes them, and thus `types` essentially can't be used in
P3, it now only contains "interpreter" types which can't trivially be
obtained elsewhere (e.g. GeneratorType, CodeType, TracebackType) and
tooling to dynamically create new types (added in 3.3).
Convert a bunch of types usages in yaml_import to use the
corresponding builtin types.
fixers:
lib2to3.fixes.fix_types
#8530
The editable list view (and the x2manys) have been reimplemented, but
the user experience was not totally (this is an understatement)
polished. With this commit, we reintroduce a good functionality:
pressing enter on the last line of the list creates a new line.
Also, this commit removes a 'debug: true', leftover by someone with a
trigram starting by F and ending by WI.
When we load a field data with many2many_tags widget, there is no views in the
field info but instead we need to fetch the default fields,
e.g. color, display name and id.
Before this commit, all the fields with value `false` on record creation
were deleted from the given parameters for the `create` rpc.
e.g. it was impossible to untick a checkbox in the settings, the `false`
value was not saved in the created record.
When a partner has a lot of contacts, the computation of the issue total
takes a lot of time. Indeed, it performs the computation for the
partner, but also for all the children, despite the fact that the amount
is not displayed.
opw-726355
Activities now have recommended next activities. Based on next activities
configured on activity types, it allows to implement light workflows
using next activities feature.
This feature was removed when refactoring crm activities to generic
activities. People asking to remove it were visibly wrong and it is
now implemented back as it was in v10.
Currently the amounts of all invoices (linked to sale or purchase
journals) is summed regardless of these invoices being bills or
refunds, this means e.g. if you create an invoice for 1000 then a
refund for 500 on this invoice, the dashboard will display an
"awaiting payment" total of 1500 which while technically correct is
not really logical or helpful from a user's POV.
Fix summation to take in account the invoice type (invoice or refund)
and remove refund amount from the total amount.
Intent validated by @lap-odoo, also not ignoring or removing refunds
from count to avoid situations like "0 Awaiting Payments [for] $-1200"
which would be really strange.
OPW-728860
This module adds some extra fields to the partner model, in order to be able
to manage extended addresses. However, those extra fields were not present
into the company model, thus making partner's addresses and company's
addresses displaying somewhat inconsistent.
This change takes those fields that were already present into the partner
model, and adds corresponding fields into the company model and view, so
addresses from both models are now shown the same way.
Closes#16547
To substract the included tax from the unit price when it's mapped
by a fiscal position in the POS.
To keep the same behavior introduced by this commit odoo@503820a
opw:710437
In Python 3, `raise` can take:
* nothing (reraises)
* an exception *instance*
* an exception instance `from` a traceback
The Python 2 forms `raise type, instance` and
`raise type, instance, traceback` are deprecated and should be replaced.
Fixers:
libfuturize.fixes.fix_raise
#8530
hr_holiday was the only module that used a widget=toggle_boolean on a
button in a list view. That behaviour was implemented as a column
widget in the previous list view, and was not reimplemented in the new
views. The feature is useful, but this was not done properly: it is
better to use a widget on a field (that was the intent) instead of doing
a weird hack like it was done.
With this commit, we update hr_holidays to use the ToggleBoolean widget,
which is supposed to work on every views.
Also, we fix the toggleboolean widget (it was not properly rendering
tooltips, and changes were not saved in readonly list view).
Note that it as the side effect of being better from the point of rpcs:
before, the list view had to reload itself. Also, another advantage is
that models do not need to implement custom methods (such as
toggle_payslip_status) just to toggle a boolean...
Before this commit, the code that handled buttons in list view was kind
of simple, and did not reload the view after.
But clicking on action button is not only a problem for the list view,
the form view already had something in the controller doing exactly
that. With this commit, we move that code to the basic controller, and
use the method in the list view.
Currently applying a color to a kanban item applies it to the whole
card. This creates usability issues as the content is not dynamically
updated to match the chosen color.
This commit proposes to apply the color only to the header and let the
card content standard. It helps designing cards that are always usable
and readable.
In general, I think that we can safely consider that crashes are not the
intended behaviour.
In this case, viewing metadata crashed because we tried to format a date
which was not parsed (so, a string), instead of a moment object. We
simply just parse the date before, and it works as intended.
With new records, it could happen that clicking on a button in the
header was followed by actions using the wrong id. This was caused by a
field name="id" in the view (see sale order view, in the
delivery.view_order_form_with_carrier inherited view).
In that case, the id was registered in the changes list, and caused
invalid data in the record: its data.id was set to null.
This commit solves two issues with deletion:
- deleting the last record in a form view now triggers a history_back
action, which means that the view will be changed back to the main
view (a list view for example), instead of staying in form view
- deleting a record did reload the view twice in some cases.
When evaluating a context, we need to use the server format for dates,
because the context will ultimately be sent do the server. Also, moment
objects are not known by pyeval, so they simply cause a crash (for
example, see bank statements form view, edit it, click on 'add an item')
With this commit, we make sure that the evaluation context is correct,
with respect to dates (we use the toJSON method, because that is the way
we get the server compatible date)
Default mail.alias for crm.team are currently recomputed/modified
when *setting* use_leads on the team (type changes from opportunity to
leads), but not the other way around (*unsetting* use_leads doesn't
rollback type to opportunity).
Fix this issue.
Leaves over the issue that *disabling* the global setting doesn't
recompute aliases, which it probably should.
OPW-728690
In general, with the new views, we execute immediately and recursively
all onchanges, even from a x2many in a form view. It allows for nice
interactivity, for example, recomputing immediately a total or a tax in
a sale order when an order line changed.
However, we are used to treat x2manys in a slightly weird way: for
example, if you add a line in a one2many, then click elsewhere, most of
the time, it is validated. But if the line is 'incomplete' (I mean, if
a required field is not set), the line will not be validated, but be
automatically discarded. If it was dirty, a confirm dialog will open.
So, to keep in line with that semantic, we have decided that onchange
will just not be done until the line is 'valid'. This will avoid
trouble when someone add a line, it triggers some onchange which changes
some values in the form, then click somewhere else, the line is
discarded, but the changed values persist. Most of the time, it
probably won't be a problem, because another onchange will be triggered,
but it is some useless work anyway.
Use case when it can happens (non deterministic):
- Enable product variant
- Have different stock moves with the product variant
- Click on the stock moves in the section reports
- Switch to pivot view
-> Traceback : can't find path of null
This happens in the js in the function find_path_in_tree,
this function try to find path for children object. There is
a condition root.children[i].path[l] === path[l] (2 strings
comparaison).
With product variant this condition can be overpass when it should
have been triggered. The product path string is represented as follow
[Ref]Name(variants) -> Sometime the variants in the string do not have
the same order and thus the condition is never true and the function
return null instead of the correct root.
This commit corrects the name_get function for product product
in order to always return the variants in the same order.
The introduction of the new RPC framework (see
0df9968433,
e574027056 and
2106e3dd2e) replaced RPC calls made with
web.DataModel by web.rpc. The arguments in the fail callbacks for
these are different.
For web.DataModel an error object and a jQuery event are passed. The
jQuery event had to be DefaultPrevented to avoid web.session from
trying to show a traceback dialog.
For web.rpc an error type and an error object are passed. This caused
errors because the code was calling preventDefault on the error
object. Because it bypasses web.session entirely a traceback dialog is
never shown, so we don't have to worry about preventing it anymore.
Now that users with restricted access can view the dashboard graphs,
access rules need to be applied upon fetching the data.
This commit also adds the missing access rules on sale reports.
rename values of selection field to actual model names.
this prevents the need of a separate function to get the sql table
and allows to get direct access to the model.
(needed for the next commit)
Current sales channel configuration for graphs is complicated for users.
This commit attempts to simplify the form view by renaming labels on
selections depending on the chosen graph model.
It also adds the option to group by stage for the pipeline graph and
hides the team members for the POS and eBay sales channel.
- swap `groupby` with `period`
- for `sale` and `invoice` graphs:
- rename label: `period` -> `scale`
- rename graph periods' selection items: `This Month/ This Week/ This Year` -> `Last Month/ Last Week/ Last Year`
- for `pipeline` graph:
- rename label: `period` -> `expected to close`
- rename graph periods' selection items: `This Month/ This Week/ This Year` -> `Within a Month/ Within a Week/ Within a Year`
- rename graph groupbys: `Day/Week/Month` -> `Expected Closing Day/ Expected Closing Week/ Expected Closing Month`
- add new graph groupby: `Stage`
- remove lead management fields for ebay and pos channels
- hide `Assignation` page and `Domain`, `Assigned Leads Count` and `Minimum Score` fields
- in dashboard page, make content field readonly
Indeed when having a lot of available channels searchbox is displayed
quite low in the screen. This is annoying. This commit improves that
behavior by putting the searchbox above channels.
Purpose
=======
Clean the menu on Settings as some the items are really advanced
Specification
=============
- Keep Menu : Dashboard - Users & Company - Translations - General Settings
- Google drive is already on General Settings - no need to repeat Remove
- and add to debug menu + : Postal Printings - Database anonymization
Christophe Matthieu