This commit improves the inline tree view for 'Website popups' for the
mailing lists with following changes:
- disables creation from the tree view as it should always be done with
the fronend
- adds last updation date and create date in the tree view
- hide website popups page/menu in form view if no popup is there
TaskID - 2312996
Steps to reproduce the bug:
- Create a Job Application without Applied Job
- Refuse/Archive it.
- Restore/Unarchive it
Bug:
- KeyError raised due to missing `False` in `default_stage`
Fix:
- Add `stage_id` if Applied Job is selected on the application.
opw:2513147
closesodoo/odoo#70077
X-original-commit: b0dc16e44d027bf27ec501d922459bf0f1db8550
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>
Steps to reproduce the bug:
Create an accounting entry AE with $ as default currency
Add a line L1 with 10 € and a tax of 15%
Bug:
The added tax line was 0.75€ instead of 1.5€
opw:2510338
closesodoo/odoo#69995
X-original-commit: 28e85cdbbd499b3fa826c15d4058aa4b83b993c9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Co-authored-by: smetl <las@odoo.com>
Steps to reproduce the bug:
- Go to Attendances > Manager > Attendances
- Remove Check in value of an hr.attendance record A
- Set Check out to A
Bug:
A traceback was raised
opw:2513143
closesodoo/odoo#70088
X-original-commit: c462782f66d720266e7e8e7f616fc26c23f009c8
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider a project P set with analytic account AA and company C
- Allow timesheet on P
- Let's consider a task T belonging to P
- Set AA with comapny = False
- Try to encode a timesheet on T
Bug:
A UserError was raised because the field company_id on account.analytic.line is required
opw:2486034
closesodoo/odoo#70086
X-original-commit: b3dc922cb45bdd4c2778bea784b540b1723c8fc1
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The goal of this PR is to solve some issues with the last AppStore review.
Without these changes, we are no longer able to update the mobile app on iOS.
Here is a summary of the feeback we received:
> **Guideline 2.5.8 - Performance - Software Requirements**
> https://developer.apple.com/app-store/review/guidelines/#software-requirements
>
> Your app includes a dashboard view that presents multiple windows at once.
> The Apple iOS Human Interface Guidelines allow multiple screens in an app. However, access to these screens should always be sequential, not simultaneous.
>
> _Next Steps_
>
> To resolve this issue, please modify your app to provide an alternate way users can accomplish the same task in a single screen or sequence of screens.
>
> **Guideline 3.1.1 - Business - Payments - In-App Purchase**
> https://developer.apple.com/app-store/review/guidelines/#in-app-purchase
>
> We found in our review that your app or its metadata provides access to mechanisms other than in-app purchase for purchases or subscriptions to be used in the app, which does not comply with the App Store Review Guidelines. Specifically:
> Your app includes an account registration feature for businesses and organizations, which is considered access to external mechanisms for purchases or subscriptions to be used in the app.
>
> _Next Steps_
>
> To resolve this issue, please remove features, account registrations links, and any other fully qualified links to your site that could indirectly provide access to external purchase mechanisms.
> If you have any additional information to provide regarding the digital content and services in your app and how the guidelines apply to them, please reply to this message in Resolution Center and let us know. If there is information you'd like us to consider in our review of future submissions, please feel free to include it in the App Review Information section of App Store Connect.
>
> _Resources_
>
> Learn more about our policies for apps that offer paid digital content and services.
closesodoo/odoo#70093
Task-id: 2483253
Forward-port-of: odoo/odoo#70051
Forward-port-of: odoo/odoo#68351
Related: odoo/enterprise#18035
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
According to the app-store guidelines we are not allowed to sell from
the iOS app.
Our updates are currently blocked because of this.
In the rush, we have no choice but to hide the 'learn more' button
displayed on each app. This redirects the customer to the documentation
page where you can find subscription links.
And this is unfortunately not allowed by Apple...
Source: https://developer.apple.com/app-store/review/guidelines/#business
Related PR:
https://github.com/odoo/mobile-ios/pull/102https://github.com/odoo/mobile-ios/pull/103
Task-id: 2483253
X-original-commit: a812660e284068802e24d9dd422e4dd15341e716
- Improve product.product & product category population: Add "random"
types, prices, and product categories to product. Specify some product
categories as children of others (populate the `parent_id` field).
- Provide product template and product attributes population
- product pricelist population
task-2446266
Co-authored-by: Feyensv <vfe@odoo.com>
`t-raw` is a relatively regular source of issues, not just because it
gets misused (though that happens) but because it's a form of action
at a distance: a commit adds a `t-raw` with a checked input, this gets
validated and merged, then the *input* gets modified or overridden or
... and the devs & reviewers don't realize it will end up in a
`t-raw`... and we've got an injection vector.
The markupsafe package (on which we already have a hard dependency)
turns out to have a solution for that: if the parameter to
`markupsafe.escape` has a `__html__` method, it will just call that.
It also provides `markupsafe.Markup` which defines exactly one method,
and furthermore will automatically escape the parameters to its
methods (which can be a bit disconcerting for some) as well as
formatting parameters e.g.
Markup("foo %s %s") % (a, b)
will automatically escape `a` and `b` before they're merged into the
format string, and will return a markup. Obviously that doesn't work
the other way around (because `str.__mod__` and `str.format` always
return a string). It does work for concatenation though.
This means if we can use `markupsafe.escape` as the standard escape
function (which is a good idea since werkzeug [is deprecating
`werkzeug.utils.escape`
anyway](https://github.com/pallets/werkzeug/issues/1758)) we can
leverage this property by requiring the *sources* to be properly
tagged for them to be directly injectible, this means in the scenario
above the payload will either be properly escaped OOTB or it will
break the existing system, but either way it should not be a
*security* risk. And we can easily flag mentions of `Markup` or
`__html__` for security review.
This PR updates `qweb` to use `markupsafe.escape` as its escaping
function, and adds a warning to `t-raw`. It also updates a number of
APIs to make them markup-safe by default:
* html_escape (that's actually what `markupsafe.escape` does on all of its own)
* html_sanitize
* the output of HTML fields
* scriptsafe JSON
* nl2br (which internally escapes its input if necessary)
* qweb markup bodies e.g. `<t t-set="thing">body</t>` the value is markup-safe
* qweb *output*, however `qweb._render` returns *binary data*, for the
most part this is invisible because we keep using `to_text` and
`ustr` everywhere and those decode bytes to text automatically, but
`Markup` inherits from `str` so we can't just have qweb return a
`Markup`, it generates garbage. Therefore it returns
`MarkupSafeBytes`
`to_text` was also updated to let `Markup` instances pass through
unmolested. `ustr`, however, was not.
New wrapper types:
`MarkupSafeBytes` is used as the output of `qweb._render`. It extends
`bytes` as `Markup` extends `str`, though it doesn't redefine all the
utility escaping `Markup` does. For the most part:
* It decodes to a `Markup`.
* It defines an `__html__` which decodes to and returns a `Markup`.
`_ScriptSafe` is the new output of the scriptsafe JSON module. It
defines its own `__html__` which applies script-safe escaping at point
of use, it doesn't use the `Markup` wrapper to avoid issues of
unescaping and double-escaping related to attributes, with which
script-safe escaping is not compatible.
A few other notes:
* `to_text` was updated to let `Markup` objects pass through
unmodified, `ustr` was not updated thus.
* The `Text` fields used through `t-raw` were converted to `Html(...,
sanitized=False)` (at least when they could not be sanitized
e.g. header contents and friends).
* Digest was completely untested, but the test I added is not entirely
reliable, sometimes records go missing and I'm not really sure why.
* Running Odoo with `-b` might be a good idea: while Python 3 removed
implicit conversions between text and bytes, this means
`str(b'foo')` now generates the value `"b'foo'"`. Because `Markup`
extends `str` it has essentially the same behaviour, and passing
*bytes* to `Markup` is basically a garbage generator.
closesodoo/odoo#68072
Related: odoo/upgrade#2315
Related: odoo/enterprise#17228
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
qweb returns bytes, which would be stored in a dict's `body_html`,
which would then be stringified *but not decoded*.
Running with `-b` this gets flagged, it's probably better to fill the
dict with what's actually expected (text).
Mark computed field as Html (might not even be necessary as it's
computed by rendering a template but... can't hurt?)
Also update the template to use attf, seems dumb to format by hand.
The *_msg fields are HTML fields so there's no reason to do anything.
A few of the values are a bit more debatable though:
* Thanks_msg seems pretty much never used?
* The `message` value comes from `state_message`, looking at how
that's set it doesn't seem like there's any reason for it to ever
contain markup?
t-raw is used to inject safe-ified JSON into a script tag.
The scriptsafe json pseudo-module takes care of that, so remove
explicit escaping and use a script-safe JSON dump.
* The acquirer messages should be Html fields and thus working.
* The sort thing is the result of a template rendering, and hasn't had
any need for raw rendering for a while anyway.
* Convert ribbon.html to an Html field, so qweb considers it
markup-safe. Disable sanitisation otherwise the sanitiser wraps it
in a `<p>`, and show the field as a char widget (same as currently),
which requires adding an explicit view (though that lets us lay it
out a bit better, it was weird to have the required `html` at the
top left and the required `html_class` at the bottom right with the
optiona color fields inbetween).
Looked at the color picker widget for banner color selection, but
that doesn't generate actual CSS colors so it's useless.
* Converted embed_code to HTML, needs to be unsanitized as it contains
an `<iframe>` and those get stripped by sanitization (similar to the
same field in website_slides).
Convert `embed_code` to a computed HTML field so it's considered markup-safe.
It needs to be sanitize=False because we're putting <iframe> elements
in it. Those get stripped by sanitize.
Convert `custom_code_*` to `Html` with no sanitization, such that qweb
considers them markup-safe.
`base_popup_options` value comes from a rendered XML body so should
already be safe
raw -> out in the extended website info template, not sure why this
was even raw
Also mark robots_txt as an unsanitized Html field, that's
not *actually* true but it is true enough for our purposes, especially
since the field gets edited through a text-mode wizard.
One was always there, the other was apparently added due to a double
escaping issue.
Seems unnecessary either way:
- Additional_title should always be set via markup, meaning it's
marked as safe (if necessary).
- The other one is less clear but neither website.name nor
company.name should contain markup so...
Trying to repro the issue reported at 1725212, still seems to work
fine.
`href` is `href="...`, so if the input is a Markup object it will get
escaped on `html.replace`, which means it will not actually match the
text we're looking for.
Therefore mark it as `Markup`, because that's essentially what it
is. This should have no effect if `html` is an `str`.
Done this way so `_message` can be overridden with custom
markup. Should now work properly ootb: `final_message` should be a
`Markup` from qweb rendering, if `_message` also is such, the merge
should happen without further escaping of either value.
Note: needed to convert the str.__mod__ call to a concatenation as
otherwise the markupness information is lost. That's probably a
recurring issue.
The process of making HTML reports palatable to wkhtmltopdf is a bit
involved, including various renderings intersperded with
processing. This means bits of HTML are created, which are
processed (via lxml) before being fed into further templates.
On step 3, the previously processed bits need to be marked as Markup
lest they be escaped again and lead to... odd results.
Also explicitly provide encoding for one case where it's not entirely
necessary but can't hurt.
Also un-escape <base> in report templates, it seems completely
unnecessary. And try to move it to the correct location to the extent
that that's possible: per-spec, it should be in the head, not outside
the document entirely.
* QWeb bodies should be markup-safe so `0` should always be
markup-safe.
* `head` is qweb-rendered so the same.
* The `json` pseudo-module in qweb templates is `json.scriptsafe`,
which should be markup-safe.
* fix generation of preferences markup so everything's properly
safe (and flag as markup)
* tips should be the result of templates rendering and thus safe
* same for body
* The result of `plaintext2html` is fully controlled and
markup-safe (the first thing we do is escape the input).
* For `append_content_to_html`, we assume the inputs are HTML and the
output is thus always properly HTML.
Alternatively, we may want to `Markup("%s%s") % ...` and require the
inputs to be properly marked? That seems like a good idea.
* In `_replace_local_links`, applying re.sub will strip out the markup
mark, so store it and reapply it on output if necessary.
That one is a big gnarly, because if the input to ustr is
markup-safe bytes (e.g. qweb rendering output) then the output is a
Markup object, but if the input is str then the output is str, so we
need to check before and after unless... we update ustr to check for
subclasses instead of exact type?
* In `_prepend_preview` the issue is similar to that of
`append_content_to_html`, though in this case we should *not* trust
the input, so we can flag the "parent document" as Markup and format
the preview bit in.
* And since we're marking mail's jinja output as safe, do the same for
web and iot.
Sadly there doesn't seem to be any hook for doing that at the
environment level of jinja, so every `Template.render` site has to
be marked.
`markupsafe.escape` always escapes single and double quotes, and
escapes them to their numeric values rather than symbolic
According to pallets/jinja@f35e28154f,
this is for compatibility with HTML 3.2: the only named entities in
the HTML 3.2 DTD are `amp`, `gt`, and `lt`.
Update tests to match.
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
Scenario:
- add a file in mass mailing editor => an icon is added linking the file
- save
- edit => the icon is replaced by a generic icon
- save
- send mail => no icon is shown in email received
The system is using eg. `data-mimetype="pdf"` to show the icon, before
12.0 this worked but in saas-12.3 the system uses mailing.mailing
body_arch's field that is sanitizing attributes and remove it on save,
so the icon is only working in received email if you save one and only
one time after adding file inside the mass mailing.
opw-2474053 (ticket for similar issue in 14.0)
closesodoo/odoo#70057
X-original-commit: 7e14515b84d8081557517df7e9dc7d8c0d17f2be
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#70058
Forward-port-of: odoo/odoo#69993
Forward-port-of: odoo/odoo#69927
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug :
- Create a French company
- Go to accounting settings > in “Fiscal Localization” install French accounting
- Install “l10n_ch_qriban”
- Go to contacts > Configuration > Bank accounts
- Create a new bank account > add a French company newly created in the “Account Holder” field
Problem:
The specific fields to a Swiss company appear.
Solution :
Check if the country of the company encoded in the “Account Holder” field is Switzerland.
opw-2504699
closesodoo/odoo#70011
X-original-commit: 326dc3f7001f605d7ebb929740ed8478fce20e7e
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a user U not in group group_system
- Log with U
- Create a vendor payment with payment method Checks
- Print it
Bug:
An access error was raised because U didn't have the rights to write on model ir.sequence
opw:2513014
closesodoo/odoo#70062
X-original-commit: 11376c88e0068a0bece0b0b56ffd4a9f296ffb87
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When the user submits a form, a lead will be created but the language
won't be the one selected by the user.
To reproduce the error:
(Enable debug mode)
1. Settings > Translations > Languages
2. Activate another language L_other
3. On website, add a form:
- Action: Create an Opportunity
4. Add an existing field: "Language"
5. Submit the form
- Language must be L_other
6. Consult the new lead
Error: The language is not the selected one.
OPW-2486276
closesodoo/odoo#70050
X-original-commit: 8d6a971a8dba860fe7c2a453c3a15f62916f656a
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps:
- Go to Inventory / Products / Products
- Create a product (2)
- Storable Product
- Cost: 10
- Click Update Quantity
- Create a new quantity line with 3 in On Hand Quantity
- Update the line with 1 in On Hand Quantity
- Go back to the product
- Click the "Forecasted" smart button
Bug:
The on hand value is 30 instead of 10.
Explanation:
When `location_dest_id` is the current location, it is used to specify
that a given quantity has been added to this location's stock. However,
when removing a quantity, the move goes from the current location to a
virtual one. The current location is, in this case, stored in
`location_id` and the destination is the virtual location.
This makes stock removals not appear in the on hand value since we only
filter the layers on their move's `location_dest_id`.
This commit assumes that a move always goes from or to a virtual
location and checks if the current location is in `location_dest_id` or
in `location_id`.
opw:2510911
closesodoo/odoo#70038
X-original-commit: 978853a6355e36e81752bf0714102f519a6a7931
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Use the last version of raspberry pi os to build the IoT Box
We don't hold anymore the firmware-brcm80211
closesodoo/odoo#70037
X-original-commit: a8c952fe477d22f5a88696df44e63faca13cba06
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this update if you would update the module the default livechat details would be reset.
By wrapping it in a no-update they're not updated with a module update.
closesodoo/odoo#70029
X-original-commit: 45c330c1e44d6a9526596b5ec1dfbff317579b68
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Scenario:
- add a file in mass mailing editor => an generic icon (instead of lower
version where icon depended on mimetype) is added linking the file
- save and send mail => no icon is shown in email received
The system is targeting `a[href*="/web/content/"][data-mimetype]:empty`
to add real image inside instead of using background-image attribute
which is stripped in sanitized.
With this commit, data-mimetype is not removed when image processing
attributes are removed when a file is inserted.
opw-2474053
closesodoo/odoo#70022
X-original-commit: eb3772508ce518ff3f84724eebbe43fd1e040d77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose of the commit is to do the generic improvement for the
refactoring of some module's view.
So in this commit, done the following changes:
- Reporting > Tasks Analysis , average progress of each task display correctly
- In project overview:
- state button is fit correctly in report view
- In task quick create, added placeholder for name field
- In Product form view:
- service_tarcking field: rename 'don't create task' into 'don't create a task'
- display the share button if privacy_visibility should be portal
- remove the 'Documents' stat button
- In Tasks list view, allow users to edit the stage of the task in batch if the project is in the context
- In project kanban view, remove the 'profitability' link and the corresponding stat button on sale.order
task-2458123
closesodoo/odoo#68146
Related: odoo/enterprise#17201
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
dht-odoo