Even if only accessible when writing some custom code, the path option
of Profiler looked a little dangerous from a security point of view,
since this option allows to write the result of the collector anywhere.
This shouldn't be a problem, since Profiler shoudn't be accessible
inside a safe_eval() and the path param cannot be user defined, but this
is still a risk.
An alternative option would have been to give a file descriptor instead,
so that the user must have access to `open()`, which is unlikely inside
a server action. This alternative has some disadvantages, though,
because the file descriptor should be given when creating the profiler,
or at least before `__exit__()`, removing the possibility to add the
number of entries in the filename.
This commit proposes another solution: add a generic way to output the
profiler as a json text. The result can thus be saved the way the
developer chooses. A utility method format_path() will help to format
path the same way the profiler did before this change.
The usage of an additional optional context manager leads to the usage
of ExitStack. Unfortunately, this changes the initial format quite a
lot, decreasing readability and adding a loop on context managers, even
if there should be only one most of the time (request).
This commit proposes to a nesting utility for the profiler, allowing to
nest another context manager inside a profiler.
This solution allows an easier integration into http.py, avoids to
manage the "enter_context" case when recovering the init stack and can
be useful in other cases.
Improvement of get_dispatch_context_managers conditions and styling:
- Check profile expiration very first.
- Add an additional check for odoo.evented. Profiling will crash on an
evented server. Only longpolling should use evented servers, it but
this is more future proof.
Apparently libsass has never actually supported compound
selectors (or at least never the way people interpreted it should
work).
Therefore since libsass 3.5 (July 2017) that is deprecated and emits a
warning. Which is problematic because libsass is also hard-coded to
emit its deprecation warning to stderr[^1], resulting in a
few issues:
* because it's not decorated (let alone as a warning) it's not really
noticeable on the runbot or in most dev logs
* but because it's not associated with a logger it's basically the
only thing which shows up when running in `--log-level=warn` (as
it's printed at least once per tour)
* and it's pretty gnarly to get the information back in Python as,
again, hard-coded to stdout
odoo/odoo#70927 explored messing around with fds to intercept the
writes and re-emit them to the proper location, but that was
considered a bit too iffy.
And of course the intent was always to eventually fix the warning
itself, which qsm provided for in [a comment][fix-extend], the
important bit was the extension of `:disabled` so that's what's left
here to fix the warning. The logic of the fix is that the loader is
always used with the `form-control` class (internally) and the
`:disabled` part of the `form-control` styling is what we really want
to copy over. It's possible that third-party lose the styling if they
use `o_wysiwyg_loader` alone (without an explicit `form-control` next
to it) but that seems like an unlikely situation.
[^1] libsass 4 (sass/libsass#3135) surfaces warnings at the API level,
and removes the hardcoded / direct stream writing
[fix-extend]: https://github.com/odoo/odoo/pull/70927#issuecomment-847964413closesodoo/odoo#71667
X-original-commit: 5c2c6b881152630ffbf68d55c7c77fa2234f3ac1
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The common mistake of method instead of method leads to the parameter being ignored.
Add a warning to ensure no other controllers are defined this way
closesodoo/odoo#71571
X-original-commit: d0048ef115985a24eec1e47ceb146f4a98f71b38
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, to identify records based on state, in most of the list views we
use 'badge' widget on 'state' fields which can be decorated as needed.
However, for the list views, best approach would be to also add list
decoration along with 'badge' widget so that the whole line is colored
and it's easy for user to 'scan' the information
This commit improves the behavior adding decorations to several list-views.
To check the list of changes, kindly see the task specification
Apart from that, this commit also improves label of the module state from
'Not Installed' to 'Uninstalled'.
TaskID-2527119
closesodoo/odoo#71367
Related: odoo/enterprise#18587
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit add tests to ensure every dispatch flows redirect to a 301 if the
requested URL has a trailing slash.
It also ensures the URL params are not lost in the process.
- Basic controller: `/my/?a=b`
- Website Pages: `/my-page/?a=b`
- Basic controller with language: `/fr_BE/my/?a=b`
- Website Pages with language: `/fr_BE/my-page/?a=b`
- Homepage with language (special case/controller): `/fr_BE/?a=b`
opw-2505818
opw-2513575
closesodoo/odoo#71065
Community: https://github.com/odoo/odoo/pull/71065
Enterprise: https://github.com/odoo/enterprise/pull/18615
Related: odoo/enterprise#18615
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* http, http_routing, website, website_sale_comparison
At an crawling engine/SEO level, having trailing slashes or not in URLs doesn't
change anything.
Still, whichever solution is chosen, it should be done consistantly: either all
URLs have trailing slashes, or none of them have it.
See https://developers.google.com/search/blog/2010/04/to-slash-or-not-to-slash
" Be consistent with the preferred version. Use it in your internal links. If
you have a Sitemap, include the preferred version (and don't include the
duplicate URL). "
opw-2505818
opw-2513575
Community: https://github.com/odoo/odoo/pull/71065
Enterprise: https://github.com/odoo/enterprise/pull/18615
Before this commit, `/fr_BE/` and `/fr_BE` would both be served without one
being redirected to the other.
That would be considered as duplicate content, as 2 different URLs would be
serving the same content.
opw-2505818
opw-2513575
Community: https://github.com/odoo/odoo/pull/71065
Enterprise: https://github.com/odoo/enterprise/pull/18615
This commit fixes multiple bugs when serving a `website.page` which has a
trailing slash:
1. We use a 301 instead of a 302 as it is done for every other dispatching
flows (mostly through the redirect in `_postprocess_args()`)
2. The language is no more lost during the dispatching, before this commit
`/fr_BE/contactus/` would redirect to `/contactus`
3. The URL params are no more lost during the dispatching, before this commit
`/contactus/?a=b` would redirect to `/contactus`
opw-2505818
opw-2513575
Community: https://github.com/odoo/odoo/pull/71065
Enterprise: https://github.com/odoo/enterprise/pull/18615
- Rename Priority to Favorite
- Move the priority field star icon in the kanban view
- Remove the sequence field from the list view
- (website_sale) make the favorite column optional in tree view
- (website_sale) keep same order in kanban view than in list view
task-2496758
closesodoo/odoo#69657
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Automate activites linked to plan on certain triggers.
To automate onboarding and offboarding processes, we can now define
plans that will activate upon triggers, such as employee creation,
departure (archive), contract start or contract end.
Manual plans are still possible.
Upon activation of a plan, a message will be added to the employee's
chatter with the name of the plan.
More options have been added related to when to schedule the plan's
activities.
The blocking mechanism has been removed (the plan would not launch if an
activity could not be started, due to lack of information), failed
activities will now be logged into the employee's chatter.
The list and kanban employee views have also been updated to include
info such as first contract date and activity information.
Task ID: 2489095
closesodoo/odoo#68451
Related: odoo/enterprise#17343
Related: odoo/upgrade#2314
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit there no general purpose snippet to embed HTML code
in the page.
After this commit there is a new Embed Code snippet that allows the user
to include any HTML within the page.
task-2517473
closesodoo/odoo#68019
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Re-introduce the changes added by commit 783a8e22a9
- It seems like Ogone has a bug on their side. Even when configuring
the encoding to UTF-8 on their back office, when signing a request
containing non ISO characters the signature we send do not match
the one computed by Ogone.
By calling the URLs suffixed with `_utf8` the issue is fixed.
closesodoo/odoo#71672
X-original-commit: f435ad2d69c7910139cd3ea6a47576399fb4d882
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
The were few times where we ended up with a infinite recursion while clicking on an order in the order management screen.
This lead to a browser stuck.
Now we don't use a temporary screen anymore and use the same mechanism of the receiptScreen to print the order.
closesodoo/odoo#71668
X-original-commit: 2ea13121cf82c4c9b069363cfd2ef2857fc8ccaf
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before it was impossible to use the order management screen in pos
restaurant if there wasn't any current order.
X-original-commit: be40ff84f7f86c30528e911cba387884e8ca9722
Currently, if someone browses the website as incognito without login and
registers to a free event then its attendee is created. However public
user's partner is set as customer.
With this commit booked_by field will be empty when registering to a free
event without login.
closesodoo/odoo#69810
Task-id: 2508558
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
Range.extractContents resulted in an icon being duplicated when trying
to just apply a link to it.
closesodoo/odoo#71354
X-original-commit: 1a9423a223dcd049d939bfe62fbcbd5659a5c808
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The `Configuration > Odoo Payments > Account Configuration` menu entry
leads to an external page and must be blacklisted in the click_all test.
closesodoo/odoo#71651
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
What are the steps to reproduce your issue ?
1. Create new contact
2. Set compagnie type as Individual
3. Set address type as Contact
What is currently happening ?
Address label is shown as "Company Address"
What are you expecting to happen ?
Show "Address" in case of Individual company type
opw-2504878
closesodoo/odoo#71618
X-original-commit: 0248f1735c31d039446f2a7f25148dcb99c09153
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
When you are selling with invoices to multiple partner having the same
commercial partner, you get a singleton exception.
So now we are looping on the created move lines
closesodoo/odoo#71583
X-original-commit: 369331dfdc144cf852c80c99d00ce8d5da843be1
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Not sure exactly because of which change, but channel partner is now created
with its default is_pinned value (True) taken into account, which was not the
case before. This is a good change in general, but the livechat code relied on
the old behavior.
This commit makes it explicit that in this case the value should be False, and a
test is added to guarantee it once and for all.
This commit also fixes an issue during init messaging, where ids of res.partner
were searched instead of ids of channel.partner.
task-2547806
closesodoo/odoo#71647
X-original-commit: 2088883c4f6dda9dd3ccddc14a7b9da68ee873cd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The "o_mail_snippet_general" class implies a background color but when
coloring the snippet that color was applied to its parent. This ensures
that the color is applied to .o_mail_snippet_general instead.
closesodoo/odoo#71500
Related: odoo/enterprise#18619
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Colorpicker snippets target <td> elements while these sometimes contain
a <div> which is background-colored in css. In consequence, when using
the colorpicker to change the background color of the snippet, the
colored <div> came in front of the element of which we tried to change
the color. This ensures the snippets target the <div> instead when the
<td> itself is marked as non-colorable via the "o_mail_no_colorpicker"
class, as this is then in fact the element we want to color.
Enterprise themes need to be adapted to this new behavior.
Mass Mailing needs to extend the registry of wysiwyg snippets but
couldn't do so because they didn't live in the same window. This moves
the mass mailing snippets to the top window.
Purpose of the commit is, User/validation errors are sometimes not
correct in English and/or quite obscure and don't help the user
understand/solve the issue. so some copywriting should help make
the experience better.
So in this commit, re-word the several validation and usererror message
and als make the timesheet_task_id field required when the
timesheet_project_id field is set,
closesodoo/odoo#70796
Taskid: 2513067
Related: odoo/enterprise#18386
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This commit adds the possibility to force the form submission by pressing the
CTRL+Enter keys.
Previously, it was not possible to submit a textarea answer using the keyboard.
Task-2484885
closesodoo/odoo#68310
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a new chart at the end of a scored survey.
Previously, you could see your "Overall Performance", meaning what was your
percentage of correct/partially correct/incorrect/skipped answers for all
the survey scored questions.
Now, we added a new chart new to it that shows the percentage of
correct/partially correct/incorrect/skipped answers but for each section of the
survey.
This allows the user to see in which section(s) he did the most mistakes.
Task-2484885
This reverts commit 3cf66c4
Prior to this commit:
- All employees who's user is an owner of a task of the project were shown in the
project overview.
After this commit:
- Only employees that have a encoded timesheet in the project will
be displayed in the project overview.
Related PR: #67726closesodoo/odoo#71638Closes: #71588
X-original-commit: 171c9ec7242bd12d7a304e61eb7908aaae18b531
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This method only expects to be called as POST and should not be called
with GET.
This commit enforces that.
[CLA] Signature for sushiwushi
closesodoo/odoo#71575
X-original-commit: 00f2eeee7aa514599b40e049be46eacdcc8332fa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- 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
Xavier-Do