The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Before this commit, when you go on website config settings, you can't save.
This is because the website default lang field is not set anymore (supposed to
be set in onchange), and since it is hidden in the view if only one language,
there is no clue about the error field.
Following d0bb596f1d, x2many fields of new records are new records, meaning
that:
`self.many2one in self.x2many`
is not true anymore since self.x2many is a new record.
Also:
`self.many2one = self.x2many[0]`
is not working as before, the new record is not saved in the many2one
closesodoo/odoo#33716
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Generate a unique URL for translations and cache them forever in the
browser. This reduces the number of requests, in exchange for computing
the hash of the translations when the session object is added to the page
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Facebook API does not accept float values for height and width
parameters anymore.
closesodoo/odoo#32970
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Create 2 companies A & B
- For each company, create a website linked to a different URL and
activate 'Free sign up' and 'Specific User Account'.
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account
The user is created in company A (the company of the user template)
instead of company B (the company of the website).
We set the company of the user based on the company of the website.
opw-1962197
closesodoo/odoo#32823
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Javascript is responsible of showing the menu, potentially with some
parts regrouped in an extra dropdown, on page load (this is what we
call the "autohide" feature). This was done on both the menu and the
affix menu. It worked on the affix menu because the affix menu widget
was initialized before (by luck: alphabetical order).
Since the jQuery 3 update https://github.com/odoo/odoo/commit/bb004e3d7f3df5a5af6b2e994ec0af79e2da890f
deferred are always delayed (even if their resolve condition is met on
creation). This made the animations to be initialized in the same order
as before but their 'start' method to be delayed (as the willStart was
delayed). So what happened before was:
1) Find menus to enable affix
2) Enable affix on found menus (duplicate the menus to do that)
3) Find menus to enable autohide
4) Enable autohide on found menus (both the menu and the duplicated one
were found)
And since jQuery 3:
1) Find menus to enable affix
2) Find menus to enable autohide
3) Enable affix on found menus (duplicate the menus to do that)
4) Enable autohide on found menus (the duplicated one was not found at
step 2 since it did not exist yet)
In fact, widget starting should never have relied on alphabetical order.
The fix only consists of starting widgets on the duplicated menu once it
is ready. This is what this commit does.
However, doing this revealed another bug: if the widgets are started
only for a DOM portion like a '.a' element, a widget with a multiple
parts selector like a '.a .b' selector will not be considered, as
searching inside a '.a' element will not allow to match elements with
a selector containing a '.a'. This is in fact not really a "bug" but a
limitation, so unless we get problems because of this in stable
versions, we can only "fix" this for the current saas. This is fixed
thanks to `dom.cssFind` which already existed. This commit however
improves it to try making it more efficient.
closesodoo/odoo#32465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The UTM graph data in Website > Dasboard > Analytics is not getting
properly filtered on the basis of values of date_from and date_to on
website_sale dashboard.
The field confirmation date which is of type datetime while date_from
and date_to are of date string in local browser timezone.
Hence date_domain is not perfect as shown below on local date 29th april
2019, we would send:
('confirmation_date', '>=', '2019-04-22'),
('confirmation_date', '<=', '2019-04-29')
But in reality we could want a from midnight of week before the current
UTC day, and to current UTC now or 23:59:59 of current UTC day.
This way, the data sent back matches more what is expected, instead of
the preceding domain, we would then have the following:
- if UTC now corresponding to local now is on '2019-04-29'
('confirmation_date', '>=', '2019-04-22 00:00:00'),
('confirmation_date', '<=', '2019-04-29 23:59:59')
- if UTC now corresponding to local now is on '2019-04-28':
('confirmation_date', '>=', '2019-04-21 00:00:00'),
('confirmation_date', '<=', '2019-04-28 23:59:59')
- if UTC now corresponding to local now is on '2019-04-30':
('confirmation_date', '>=', '2019-04-23 00:00:00'),
('confirmation_date', '<=', '2019-04-30 23:59:59')
And each one will be displayed as days 22 up to 29 in line chart (with
local today 29 being the last day of the chart and contening orders of
the current UTC day).
With these change in the UTM pie chart:
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to before yesterday UTC
- a local date that is the same as an UTC date => we see the sale from
up to today UTC instead of yesterday UTC
And in the line chart (that already had half of the fix in f6fc7c2319):
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to yesterday UTC
- a local date that is after a UTC date => we see the sales of current
UTC day + range of days (eg. for a week 7) instead of current UTC day +
range of days minus 1 (eg. for a week 6).
opw-1971539
closes#33041
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
The basic font-family offered on Odoo do not support a large set of characters
and rely on the system fonts for non-latin languages
On a system without specific fonts installed, the characters were replaced by �
For Hebrew, the system sans-serif font (at least on Windows pc) was too small.
Rely on the unicode-range range CSS descriptor to load a font only for a
specific range of unicode code.
https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-face/unicode-range
This way, the fonts are ignored for English text (and you don't have to load
the fonts of every possible language).
Add Noto fonts that covers many charsets.
There is an heavy version for many charset and lighter ones for Arabic and Hebrew
More ranges can be added later
Serve the fonts on our CDN to avoid shipping several MB of fonts for everyone
but lazyload it when needed.
Fixesodoo/odoo#32228Fixesodoo/odoo#21781
Example where the issue occurs:
- Publish an event
- Go to the website, register for that event
- At confirmation, when the email address is requested, click quickly
several times on the 'Continue' button
Several registrations are created since nothing prevents multi-clicks.
The stateful button feature of the `button.js` jQuery plugin has been
dropped in Bootstrap 4 (see [1]).
[1] https://getbootstrap.com/docs/4.1/migration/#buttons
opw-1958580
closesodoo/odoo#32571
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The recent refactoring odoo/odoo@f296992 wrongly moved the ace editor
style from `web_editor` to `website`, even though ace is in `«eb_editor`.
The editor is also used in Studio (which does not depend on website) so
the style was missing in this case.
Task 1951290
closesodoo/odoo#32384
Signed-off-by: Christophe Matthieu <Gorash@users.noreply.github.com>
Replace the font selection UI by a dropdown. Make the system generic
so that a dropdown can be used for any set of options.
task-1942241
closesodoo/odoo#32437
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Previously the image that we uploaded as a favicon of the website was not
resized, so it could be extremely excessive in size and resolution, and it also
was not guaranteed to be a square.
Now we always resize it appropriately and save it as an ICO file.
The default favicon is now applied to all websites instead of only the first.
task-1958000
PR: #31811
The current style on "Active users: {number}" placed it 60 pixels over
were it should be, so this was:
- overlapping "Visits" title
- not sparing vertical size (since we use "position:relative")
opw-1961605
closes#32245
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Reintroduces 5324284f5 that was reverted because in the case of an URL
like /payment_stripe/static/src/js/stripe.js directly inside a QWeb
template, we would possibly get:
/fr_FR/payment_stripe/static/src/js/stripe.js
Which is not accepted by werkzeug SharedDataMiddleware we use to serve
static data in /{module_name}/static/ directories.
Added test without changeset failed with:
- test_process_att_no_request_lang: <AssertionError>
line: self._test_att('/en_US/', {'href': '/'})
wrong result: {'href': '/en_US/'}
- test_process_att_with_request_lang: <AssertionError>
line: self._test_att('/', {'href': '/fr_FR/'})
wrong result: {'href': '/'}
- test_process_att_matching_cdn_and_lang: <AssertionError>
line: self._test_att('/en_US/a', {'href': 'http://test.cdn/a'})
wrong result: {'href': 'http://test.cdn/en_US/a'}
- test_process_att_no_route: <AssertionError>
line: self._test_att('/my-page', {'href': '/fr_FR/my-page'})
wrong result: {'href': '/my-page'}
- test_process_att_url_crap: <IndexError: list index out of range>
line: request.httprequest.app._log_call[-1],
opw-1922051
closes#32095
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
While waiting for a larger fix of the themes, force prevent overriding
of the web editor's UI CSS by themes. This is achieved by applying
`!important` on all web editor UI CSS. This is a temporary fix until
the themes CSS is fixed and/or the new web editor library is ready.
closesodoo/odoo#31721
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Yannick Tivisse