Make translation work for "Visitor" that was appearing in livechat
session to the visitor.
opw-2504461
closesodoo/odoo#70175
X-original-commit: 3b199007bd5a472d57f823a63b2b77841b14c7fc
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
It was the last remaining usage of the deprecated `_updateAfter` which is
therefore removed too.
Part of task-2258617
closesodoo/odoo#70170
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When retreiving the list of badge owners in `_get_owners_info()`,
we should apply `res.users` ir rules to be sure to respect multi-company
rules.
upg-7081
closesodoo/odoo#70182
X-original-commit: d75deff4791702e1f085b2b16247d7f7c5335720
Signed-off-by: Christophe Simonis <chs@odoo.com>
Make translation works for "Website Visitor" that was appearing when a
logged-out user open a livechat session.
note: list comprehension has to be removed since translation only search
language in direct calling method closure.
opw-2504461
closesodoo/odoo#70146
X-original-commit: 7d28f32d9be1590764883f4621df04e04c4e1f12
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When closing a POS session, if there was no sale, the journal entries of
cash in/out will not be posted.
To reproduce the error:
(Need account_accountant)
1. In Point of Sale, open Shop's settings:
- Enable "Advanced Cash Control"
2. Start a new session:
- Open POS
- Close, Confirm
3. Close session
4. Click on "End of Session"
5. Add a "Cash In/out"
- +$10
6. Set Closing Cash
7. Close Session & Post Entries
8. Accounting > Cash
Error: The $10 line is present but its status is "New". It should be
"Processing".
Since there was no sale during the POS session, the module ignores all
the accounting part. When the session is closed, the accounting part is
ignored because there were no sales. As a result, it does not post the
cash in and out.
OPW-2456395
closesodoo/odoo#70160
X-original-commit: 985f1bf5b187513f71e65ab7d2b68e25ff1bfdf1
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Can be simplified a bit by using the newer features of
`tools.file_open()` and `tools.file_path()`.
Let's do it since the PR is touching these lines anyway
for the change of resource paths.
closesodoo/odoo#69614
Related: odoo/enterprise#17855
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Turn off calendar.attendees notification during synced_events creation
to improve performances. The calendar notification are only computed
once after all the synced events have been created.
Add a flag in google_calendar.js to avoid retriggering synchronization
while navigating the calendar view if the past synchronization is still
pending.
opw: 2450259 + fixes/adaptations to 14.3 branch
FW of https://github.com/odoo/odoo/pull/69619closesodoo/odoo#70035
X-original-commit: 28ccb2b88a7793058c81aabffb43071165886f40
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Give a coherent group as otherwise we could have access errors. Simple
case: an Admin Rights user goes into a mail message form which is only
available in debug mode which sets `group.no_one` into such user. This
model is only readeable by `base.group_sytem` so an AccessError will
raise.
closesodoo/odoo#70119
X-original-commit: 8930e08213d0b6805e6fc91fa07561107ef43acc
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some features of the PDF.js library doesn't work in the
webview of the mobile apps.
Initially 'window.print' is defined as an empty function in
webviews unlike browsers where it is already ready.
After that, PDF.js needs to monkey patch 'window.print' and
saves a reference to the original definition, which is not
yet fulfilled in by the mobile app (Java part).
So the print of PDF.js doesn't work in webviews and end
users will need to download the file before printing it.
Regarding the Download button, the 'download' attribute is
not supported by the webview as you can see in:
https://bugs.chromium.org/p/chromium/issues/detail?id=432414
As there's many ways to download a file in Odoo it's not
a big deal to simply hide it in PDF.js.
Because it's quite complicated to fix this, we decided
to hide the features that don't work (Download / Print)
or don't make sense (Open file).
Note that a refactoring is already in progress in order to
avoid to patch this library in master.
closesodoo/odoo#70110
Task-id: 2200168
X-original-commit: 39225827035efe11cdc90b2a7f1ae1f24a54b136
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Sometimes while dropping a newsletter popup (for ex in blogs, events etc),
there's a horizontal scroll-bar on the pop-up due to bootstrap gutters.
This commit improves the behavior by removing the gutters on the div causing
the horizontal scroll-bar on the popup.
Task-ID - 2312996
closesodoo/odoo#61855
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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.
Richard deMeester