This commit factorizes the link.tracker.click values computation out of
the add_click method. This method is called when customers click on links
in email that are tracked in Odoo.
Purpose of this commit is
* to effectively put mass mailing related code into mass mailing.
Currently link_tracker holds code related to mass mailing which is
not in its dependency tree. Let us therefore try to be a bit modular
and add a proper inheritance in mass mailing;
* allow addons to inherit from the click values prepare method to add
specific values depending on their behavior like mass mailing adding
links to a mass mailing and a mass mailing campaign;
Currently mass mailing automatically computes the remaining recipients
to mail based on existing statistics and A/B testing. However in some
cases we would like to send the mailing on a given set of records. An
example of use is to use the mass mailing mechanism on records coming
from marketing activities. This commit adds this feature by adding an
optional parameter to send. If not given it falls back on the classic
mass mailing behavior.
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
- Brand new UI for Discuss client action (with tabs for for
Discuss client action (with tabs for Inbox, chats,
channels...)
- In mobile, conversations always open in Chat Windows
- Chat window UI improved (both mobile and desktop)
- Channels preview (used in the systray menu, and now in the mobile
UI of Discuss) improved
- Other minor less tweaks
Task #31446
PR #16995
- Extract mobile specific code for the client action to a specific
file
- Massive clean of less rules
- Unify channels preview of the systray dropdown and the mobile UI
of Discuss
- Ensure to only load the last message of each channel in mobile,
as this is not used in desktop (unless the user opens the systray
menu)
- Make livechat available in Discuss mobile UI
- Brand new UI for Discuss client action (with tabs for Inbox,
chats, channels...)
- In mobile, conversations always open in Chat Windows
- Chat window UI improved (both mobile and desktop)
- Channels preview (used in the systray menu, and now in the mobile
UI of Discuss) improved
- Other minor less tweaks
* PYMES, non-profit associations, complete (large enterprises) CoA
* reviewed taxes, tax groups
* reviewed tags, account types for reports in l10n_es_reports
Thanks for the contribution and the original work, spanish community (esp. Pedro M. Baeza).
Was task 30669. Was PR #19154
- List view: sortable icon, do not force position to right
- Mail: do not vertically reposition systray's icons
- Form view: oe_subtotal_footer, minor design imp
Purpose
=======
Now if we want to create a product supplier info, it's impossible to select the template if it has no variant, which is rather annoying.
Specification
=============
Remove the attrs
* crm, project
Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.
To define a progressbar, add this as a direct child of the kanban
arch:
<progressbar field="<name of the field to use for subgroups>"
colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
sum="<name of the field to sum or nothing to use total number of records>"/>
Also:
- Properly update record model data's parentID when moving a record
- ...
Before this commit, asking the basic model for a 'read_group' operation
was automatically followed by other operations to read groups content
('search_read', 'read', ...). This commit introduces an option to only
perform a 'read_group'.
Before this commit, when a record was moved in a kanban view, the
model saved the record change then manually updated the related groups
(to avoid performing a read_group and reloading the whole view). This
manual update can in fact be performed before the record save. This
allows customizing the save operation in some cases where a real
read_group would be needed.
Normal flow for one record's changes to be saved is:
0) (use `_setValue` for fields)
1) `trigger_up('field_changed')`
2) field manager mixin: `_onFieldChanged`
3) model: apply changes and save
4) controller: `_confirmSave`
Kanban records are using another system for an unknown reason. This
system was calling the right model functions but was not calling the
controller `_confirmSave` and was instead re-coding it. This commit
makes sure that `_confirmSave` is now called.
Performing a 'read_group' was creating new model group data which were
saving some properties of the old model group data. As KanbanColumn
widgets may not be updated in each case where we might want to re-do
a (partial) 'read_group', this commit changes the system so that old
model group data are simply updated with the useful new group data
properties (instead of being entirely replaced).
Previous kanban header was a div with `flex-flow: row nowrap`. So if
someone tried to add some stuff in it, it will be forced to stay on
the same row as the title and config buttons. This commit wraps these
row elements in a new div to allow kanban header customization (this
prepares for the kanban progressbars).
This merge provides some changes in the
expense flow.
The most important one is to reinvoice
an expense, employee set a SO on its expense
and not an analytic anymore (since it
requires special access group, ...)
This commit also bring back the auto
creation of analytic account when confirming
SO if expense product is sold (since AA is
required to generated analytic line of
the operation).
Some usability changes, and code cleaning
are also available. See subcommits for details.
Steps:
- In home, expense app icon: "Go to the expense
to attach a receipt"
- In list, on create button : "Click here to create
your first expense and add it to below."
- In form, on save button : "Once your Expense is
ready, you can save it."
- In form, point out the chatter "Attach your
receipt here."
- In list, point out record selection: "Select
expenses to submit them to your manager"
- Point out "Action": "Click on Action Submit To
Manager to submit selected expenses to your manager"
- In expense sheet point out approve “Approve the
sheet here. Tip: if you refuse, don’t forget to
give the reason thanks to the hereunder message
tool".
This behavior kind of disappear with 48ea59d46e
Moreover, since the Analytic Accounting is hidden, and
a AA on expense is required to reinvoice product on
SO, an AA should be on the SO as default value.
The main change is we use SO and not analytic account
anymore to reinvoice expense.
When encoding an expense, each employee can directly
set the SO to allow re-invoicing the expense to a
client. Before this commit, this was done by determining
the SO based on the Analytic Account (magically) on the
expense.
This solution is less confusing and more explicit for
the end user.
This commit also bring usability improvements to
improve user experience during this flow:
- better expense product view
- access group on menu items
- ...
Each move line generated from an expense posting will
be linked to the original expense. Some of those move
lines are for taxes, one for the product, ... but they
are all link to the same expense.
This will allow better reporting, and allow to access
the expense record from the move or its analytic lines
for futher developement.
The goal is to have a name_get for SO returning
a value like 'SO0002 - Michel F.'
To avoid performance problem, the chosen solution
is to add a context key 'sale_show_partner_name' to
provide the partner name in name_get(), otherwise
it will always add it and kill the performance.
This solution is preferred over adding a stored
related field for partner name (trigger recompute
when partner is renamed for all SO is bad).
Custory reading seems to denote that field names are probably already
text in the normal case, and thus should not need decoding? It only
blows up in a tour so...
* gitignore pycache folders (apparently appear for some)
* update xlwt requirement: 1.1.2 does not work with Python 3.6, 1.2 should work, 1.3 officially supports it
Split big universal RNG into view-specific schemas and moved rng based view validation
into view_validation.py file.
Adapt old views, and remove deprecated tag `version="7.0"` from views.
Thibault Delavallée