- The context used to create the Form used 'with_context' instead of 'with_company'.
- An additional message has been posted to the chatter with the original E-invoice XML from the email.
- Some code clarification were due where the e-invoice company is determined.
opw-2460485
closesodoo/odoo#71626
X-original-commit: db25a9d02c2fd836e05632ef1e27b73cfdd863e3
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider an expense E paid by the company
- Validate E and post journal entries
Bug:
Two journal entries were created:
1. Account Payable (debit) / Outstanding payments (credit) as draft
2. Expense (debit) / Outstanding payments (credit) as posted instead of Expense (debit) / Account Payable (credit) as draft
opw:2510663
closesodoo/odoo#71627
X-original-commit: 25ac51e01a2084afd7a4d5e9c4c87a50ea787b93
Signed-off-by: William André (wan) <wan@odoo.com>
Before, get_http_domain make the job,
now we force website.domain to be valid
closesodoo/odoo#71161
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Dropped adyen.payout model
- Show pos.payment on adyen.transaction
TaskID: 2129218
Closesodoo/odoo#68952
Related: odoo/upgrade#2501
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- Improved onboarding / KYC flow
- Display KYC stage for each "document" (identity, bank account,
shareholder, etc.)
- Only update to the API what's been updated by the user to prevent
undergoing another full round of data verification
- Show new pricing
- Support refund of adyen.transaction
- Simplify payouts (let Adyen automatically handle them)
- They are now automatically handled by Adyen and not manually
triggered by a cron
- "Balance" dashboard
- Show the balance per currency
- List of payouts and their status
- Handle account/transaction notifications
- Show split of fees
- Details on payment method (card country, card type, etc.) used
- Display details from the linked payment.transaction
- Verify proxy signature for notifications
- Notifications are now signed and authenticity verified
TaskID: 2129218
Closesodoo/odoo#68952
Co-authored-by: Antoine Prieels <anp@odoo.com>
Previously, the step produced an owl error do to the fact that
FormViewDialogComponentAdapter parent component was not ready in the
view.
This commit adds a timeout, that waits the component to be completely
rendered.
Associated PR : #68899
Associated task : task-2393768
closesodoo/odoo#71605
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
- The acquirer reference was never saved.
- Transactions with operation 'offline' were not processed.
- If Stripe rejected an offline payment, an exception would be raised.
This lead to Subscriptions assuming that the processing itself failed
and prevented the transaction to be processed. Instead, the exception
is now caught and the transaction's state set to 'error'.
task-2494916
closesodoo/odoo#71602
X-original-commit: e93b3b3c5b9bc86768a5d26ed456ef11cfb40734
Related: odoo/enterprise#18680
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
The profiling tools can be useful to profile a test of some execution
point but this is not convenient to identify a problem on a running
instance.
With this commit, an option available in the debug menu allows to add a
flag on the user sessions to enable profiling of all requests. Each
request will be saved in a different 'ir.profile' entry, but will be
grouped under the same session.
The profiling can be activated on all sessions, even for a public user,
but only if profiling is enabled on the database globally.
This commits also adds a speedscope view to visualize saved results in
the web client.
closesodoo/odoo#66590
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit adds tooling to profile performance and save execution by
saving stack traces and queries to a file/database in specific format.
----------
Collectors
----------
For now, three different profiling modes (aka Collectors) are available
even if a last once should be introduced by @Gorash to profile qweb
execution.
- SQLCollector (or 'sql'): Saves the current stack trace and the query
every time Cursor.execute() is called. Any query executed on the thread
will be collected, no matter the cursor.
- PeriodicCollector (or 'traces_async'): Saves the stack trace every
'interval' seconds using a parallel thread to profile the caller thread.
The python implementation was optimized to minimize impact on
performance while remaining portable and easy to enable/disable
inside a odoo execution. Higher the frequency (lower the interval),
more impactful the profiling will become on the execution and increase
memory usage. From last experiments, 1ms looks to be a good minimum for
short executions.
- SyncCollector (or 'traces_sync'): Saves the stack trace every function
call/return. This collector is obviously quite impactful on performance
and can quickly overload the memory for long executions, but this is
quite useful to understand the precise path followed by some short
executions. Any time related information will be almost irrelevant with this
collector.
A base Collector defining minimal collectors features can easily be
extended to create custom collectors if needed.
----------------
Profiler & Usage
----------------
Collectors are not supposed to be used by themselves, but should be
given to a Profiler. The Profiler will synchronize collectors starts and
stop, and manage saving them to a file of in a ir_profile in the
database.
Exemple of usage:
```
with Profiler():
do_stuff()
```
This simple example will use the default collectors (sql and
traces_async) and save them to the database. The database is defined
automatically from current_thread 'dbname' if available.
Example of usage:
```
with Profiler(collectors=['sql'], db=False, path=/home/user/logs/do_stuff_profile/{time}):
do_stuff()
```
This more complex example disable the default behavior consisting
to save to the database, gives a path where the profile will be saved
and specify to only use the 'sql' collector. Note that
collectors=[SQLCollector()] would have the same behavior since
Collectors can be either a Collector instance or a string describing the
desired collector. This allows to define custom params for the
collectors and use custom collectors if needed.
Note that it is always possible to get results after execution without
saving it since they are available on the profiler.
```
with Profiler(collectors=['sql'], db=False) as p:
do_stuff()
print(len([None for entry in p.collectors[0].entries if ...]))
```
Profiler will also save the stack below the profiler start point, and
collectors will only collect the part of the stack over this stack.
This is a good way to reduce collectors CPU and memory usage.
Collected entries will be saved as follows:
```
[{
'start': 2.0,
'context': {},
'stack': [
['path_to_file', lno, 'func_name', 'line_content'],
...
],
},
...
]
```
SQLCollector will add three additional keys on each entry:
- query (query without parameters)
- full_query (mogrified query with parameters)
- time (the 'exact' execution time of the query)
----------------
ExecutionContext
----------------
A last tool, ExecutionContext, allows to define some context on some block of code:
Example of usage:
```
def process_modules(modules)
for module in modules:
with ExecutionContext(module=module): # note the 'not linter frienldy but still convenient' 2 spaces indentation
do_stuff(module):
```
This context will automatically be added in the stack as a virtual frame between
process_modules and do_stuff in order to split do_stuff from one single frame to
one frame per module.
----------
Speedscope
----------
The saved data are in a simple json format easy to analyze, but can't be visualized in
speedscope as they are. A utility class `Speedscope` can be used to generate a format
readable by speedscope. The used format is actually the format defined by speedscope,
meaning that all features should be available using it.
The output format is evented, meaning that we need to transform a list of samples
(a list of stack) to a list of event (going in/out a frame).
This is the main task of the Speedscope, as well as combining samples from different
sources, to display SQLCollector and PeriodicCollector results mixed together.
When stored on an ir_profile, the default speedscope generation can easily be generated
with the speedscope computed field.
This class can be used as it is but will mainly be useful for the next commit.
Special thanks to @rco-odoo for the in depth review and @Gorash for support.
Before this commit, `get_base_url()` could not be called on an empty recordset.
It might be called on an empty recordset for instance when getting the paypal
payment endpoint URLs.
This commit allows that and returns the ICP value in that case.
The goal is to always use the util method `get_base_url()` instead of directly
accessing the ICP.
closesodoo/odoo#68201
Related: odoo/enterprise#17538
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Without this commit, the link to the T&C is always the web.base.url one instead
of the website one if created in frontend (eshop).
Steps to reproduce:
- Add a domain on the website, eg www.odoo.com
- Activate Terms & Conditions (settings) and select 'as Web page'
- Create an order from eshop
- The order contains a note with a link to the terms with the wrong url
Related to #68201
This commit improves the mechanism to find the best URL given a record.
To find the best suited URL, the following heuristic will be done:
- If record has a website_id, use that website's domain
- Else if a record has a company_id, use the company's website's domain [1]
- Else use the `web.base.url` ICP
The following commit will replace (almost) every occurence of ICP by the
`get_base_url()` helper method.
[1] Before this commit, there was no way to know which website was the one from
a company, has a company could have no website but could also have multiple
websites.
We now consider the first found website for a company as the company's
website. The use of a new sequence on `website` will allow user to chose
which website to use.
Community: https://github.com/odoo/odoo/pull/68201
Enterprise: https://github.com/odoo/enterprise/pull/17538
Upgrade: https://github.com/odoo/upgrade/pull/2372
task-2476101
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the date taken into account to retrieve people
activities in the project update description was the UTC date. The
activities just recorded with the context_today date wasn't taken into
account.
Failing unit tests during nightly build (when date UTC < date GMT+2):
- `TestProjectUpdateHrTimesheet.test_project_update_description_people`
"AssertionError: 0 != 1 : The number of recorded timesheet activities
is 1"
- `TestProjectUpdateHrTimesheet.test_project_update_form_people`
"AssertionError: False is not true : The description should contain
'People'"
This commit fixes the issue using the context_today(self) date as a
reference.
Fixes PR : #68899
task-2393768
closesodoo/odoo#71585
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
The 'Configure Tickets' button has been extracted to a template to ease
re-usability.
The template's structure has been modified to allow improvement about
this button's display.
We also removed some seemingly useless steps during the end-suer testing tours.
Task-2459617
closesodoo/odoo#71584
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Enable cash basis (Accounting>Settings>Taxes)
- Enable analytic accounting (Accounting>Settings>Analytics)
- Have a sale tax:
- Based on payment (Account 10100 Current Assets)
- Included in Analytic Cost
- Create a [DEMO] product with such tax
- Create an invoice with 2 lines:
- One line with product DEMO and whatever analytic account
- One line with product DEMO but no analytic account
-Confirm and receive payment
CABA entry will consider only 1 tax line, because the
2 entries are equal beside the analytic account which is not considered
in the grouping keys
opw-2507417
closesodoo/odoo#71556
X-original-commit: 2a8f777c04bdbdce77dc44d92e099612f158cbef
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
From 631019b86 /members route never fills free_partner_ids which is used
to determine pagination and filling contact on map up to maximum number
of contacts (currently 2000).
With this changeset, we fix them so the pagination should be shown if it
is necessary to display free membership partners.
opw-2513748
closesodoo/odoo#71512
X-original-commit: 107004eff7f5ebaffac27679a8d6d4f638af78af
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If you set the type (cost_subtype_id) of a new contract
(fleet.vehicle.log.contract) before setting vehicle_id you got an error:
name = record.cost_subtype_id.name + ' ' + name
TypeError: can only concatenate str (not "bool") to str
because vehicle name was False.
opw-2527268
closesodoo/odoo#70973
X-original-commit: 7d956af5106b9efe22b602af007088ce8c2c16ce
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This was required by the introduction of tax units on enterprise. When making the closing for a tax unit, it is possible one (or more) of its companies don't have proper receivable/payable accounts configured on their tax groups. If so, a RedirectWarnings is raised pointing to this view in order to configure the groups from the company. All the companies of the unit are then active in the company selector, meaning that the record rules allow choosing accounts from any company, which is confusing and very error-prone.
To solve that, we introduce a context key, used to reduce to 1 the number of companie whose accounts are considered in the domains when configuring the tax groups.
closesodoo/odoo#70588
Related: odoo/upgrade#2482
Related: odoo/enterprise#18234
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Tax groups configuration is now checked differently, and by country. Tax groups are considered properly configured if all the groups used by active taxes from that country have a tax receivable and tax payable accuont defined (by default or not) for the company.
Before this commit, the multi edition of a field using the daterange
widget wasn't really handled: only the field that was used for doing
the change (i.e. only the start or end date) was actually saved.
With this commit, the multi edit feature now supports the case where
editing a field actually triggers changes on other fields. All those
changes are displayed in the confirmation dialog.
Task 2555178
closesodoo/odoo#71545
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This merge is linked to the enterprise data_merge feature to allow to activate a 'Merge' button
on the models contextual menu.
- In order to be able to add a button to activate contextual merge action on the
target model, the ir.model form view had to be adapted to add the header.
- In mass_mailing model, a flag is added to avoid to activate the generic merge action on the model.
- On order to allow to log a message (_message_log) using a xml template, a new method has been added
to mail_thread model : _message_log_with_view.
Task ID: 2459416
ENT PR: odoo/enterprise#17553closesodoo/odoo#68960
Related: odoo/upgrade#2370
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Have an overview of the current status of a project and keep track of its progress. Share with other stakeholders where the project stands. Identify risks and opportunities and act on them accordingly.
SPECIFICATIONS
1) Status in controlpanel + access rights
- Indicate the status of the project next to its name in the controlpanel clicking on the status should open the updates kanban-list
by default, the status should be 'on track'
- users with the project > user access right level can see the status of the project
- users with the project > admin access right level can read, write, create, delete updates
2) Project Updates
- Project updates are defined with a name, Author, date, progress and description.
- The description is build based on project data, timesheet related to project and project profitability.
3) Project Updates Kanban View
- The kanban is a kanban list view with a right side panel.
- The right side panel displays various information about project
- It's possible to create milestone from the project update right side panel.
4) Project form view
- The milestone and update lists are accessible from the project form stat buttons
task-2393768
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#68899
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This commit allows to log a note and bypass notification process using a
template. The method _message_log_with_view has been added. This method
render the template using the given view and values (in kwargs) to make the
body before calling _message_log().
This process is done by the intermediary method _message_compose_with_view that
is now common to message_post_with_view and _message_log_with_view has it
follows the same template preparation process.
Task ID: 2459416
Linked ENT PR: odoo/enterprise#17553
As the mailing.list model has his own custom merge method, this model should
not be candidate to activate the generic merge method comming from data_merge
module.
This change is done here to avoid creating a bridge module in enterprise
only to add this flag. We can consider that the flag is linked to the custom
merge method itself. If a model has a custom merge method, it should be marked
as 'having a custom merge method'.
Task ID: 2459416
Linked ENT PR: odoo/enterprise#17553
In order to be able to add a button to activate contextual merge action on the
target model, the ir.model form view had to be adapted to add the header.
Task ID: 2459416
ENT PR: odoo/enterprise#16975
This commit adds information in project update based on sale_timesheet models.
In the Project Right Panel, a profitability section is added with data
from the profitability report.
In the project update description a profitability section is also added
with data from account analytic lines or profitability report.
PR : #68899
task-2393768
This commit adds content in the default project update description.
The informations added are related to the timesheeted time on project or
project tasks.
PR : #68899
task-2393768
This commit adds a right panel in the project update view.
This is done by extending each View and Controller by mixins handling
the RightPanel functionnality.
In the RightPanelControllerMixin, we use the component Adapter to launch
the Owl RightPanel Component from a Legacy Controller.
This solution is based on SearchPanel and ControlPanel implementation.
In the RendererMixin we handle some styling just as it's done for the
SearchPanel.
In the ViewMixin, we add the handling of a RightSidePanel config
parameter which is passed to the Controller via params.
The Project RightPanel Component gets information about the active
project in the context through a rpc call and render the resulting data
in a owl template. This template doen't have the ambition to be generic
but only specific to this view.
Serverside, the data are collected in a dict through few methods in
order to be easily extended.
Mixins are used in kanban and list views, each time a project update
view is added, the developper will have to extend the dedicated View,
Renderer and Controller.
PR: #68899
task-2393768
This commit aims to add a button in the control panel to easily display
the current project update status.
This is done by extending ControlPanel Component and template.
We must add a context value `show_project_update` to enable the
button in the breadcrumb and it's done only once; e.g. when we click to
see all project tasks of an active project.
The button redirects to a kanban list view of the project_updates.
The activity rng is modified in order to accept js_class definition.
Following commits will add behaviour to handle those updates and
milestones in the various views. See PR for further information.
PR : #68899
task-2393768
This commit adds project updates in project to take in stock the current
status of the project : which task or milestone changed in the past 30
days.
The project manager is able to add a status on the project update, and
edit the description of the update. There is also a chatter in which
he/she can discuss some points with other project users.
The description is build with informations retrieved from mail tracking
values or from project.* models. Those informations are collected in a
dict and rendered in a template to ease the inheritence in further
modules needs.
Following commits will add behaviour to handle those updates and
milestones in the various views. See PR for further information.
PR : #68899
task-2393768
PURPOSE
Improve mail rendering tools and prepare ground for QWeb rendering.
SPECIFICATIONS: MODEL FOR RENDERING
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
SPECIFICATIONS: COMPOSER MIXIN
This merge introduces a new mixin ``mail.composer.mixin`` used when sending
emails or notifications based on a mail template.
Main current purpose is to hide details related to subject and body computation
and rendering based on a mail.template. It also give the base tools to control
who is allowed to edit body, notably when dealing with templating language
like jinja or qweb.
It is meant to evolve in a near future with upcoming support of qweb and fine
grain control of rendering access.
Use it in survey and slides invite wizards, as well as appraisal and appraisal
survey (in enterprise). Use it in mail composer in a minimal way.
SPECIFICATIONS: QWeb
Temporarily and experimentally support Qweb rendering even if not used
functionally, to prepare QWeb templates.
LINKS
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2490
Related: odoo/upgrade#2496
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to prepare ground for future improvements by already
supporting QWeb rendering in ``mail.render.mixin``.
We temporarily support new field parameters allowing to tune the rendering
directly from field. Notaby choosing engine (jinja or qweb) can be done
from field directly. This is considered as experimental, used mainly to
prepare QWeb support.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Purpose is to have all mail template into a mail_template_data.xml file
when possible. It eases maintenance and update when having to work globally
on template records.
Also update some ``body_html`` declarations still using ``xml`` instead of
``html``.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
``mail.compose.message`` is still overriding default mixin behavior to keep
a minimal fix. Rewriting composer code is planned but will not be done with
this task. Here we keep current behavior, technically and functionally.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
In this commit we fix some glitches in slide invite process
* prevent from sending without recipients as it makes no sense;
* hide Invite link in kanban like Invite button on form view, when not
being invite-based;
* fix small issues in various templates, notably escaping in subject;
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
Paolo (pgi)