*: crm, digest, hr_expense, im_livechat, mrp, purchase, sale_management,
website
The images in the digest email are updated to have the look of the new
"Milk" Ui. We want to keep names unique, as they target different
versions. That way we can keep a v15 oriented gif for people using tips
in v15 for example.
The mobile phone image is hosted on odoo.com.
task-3338467
X-original-commit: odoo/odoo@3711d2b61b
Part-of: odoo/odoo#158351
The goal of this commit is to add a default meta description on website
homepage and "contact us" page in order to improve their SEO and avoid a
warning of type `Document does not have a meta description`. Of course,
it is still meant to be overridden.
Part-of: odoo/odoo#140453
Commit [1] introduced default images changes for the website library.
The problem is that the ir.attachment definitions are in a non-updatable
environment by mistake (apparently since forever)... so they are not
updated after update/upgrade.
This commit moves the definitions to its own updatable file, in 17.0 and
above only (ignoring potential other changes that were made in 15.0/16.0
at the time but apparently led to no issue). But this is not enough:
upgraded users will still have those ir.attachment records marked as non
updatable and will thus not be updated. Meaning that the ir.attachment
record will still reference path to images that do not exist anymore
(since [1]) and thus not display anything in related snippets, or worse:
crash on some non-robust-to-404-images options (This will be made more
robust in another update).
Note that, at the moment, we cannot solve this issue by making the
/web/image route not return a 404 but a placeholder image in that case,
for technical reasons (even though it would be consistent as this is
what is done if you try to reach `/web/image/something_with_a_typo`).
It would also be annoying to solve this problem by adding a migration
script inside the Odoo repo itself:
- It would only work if upgraded users do a -u again (unlikely).
- That would mean an upgrade script rotting in the main repo forever.
Instead, this commit chose to restore the removed images so that
upgraded users will be able to use the outdated paths. In master, an
upgrade script will be made (in the upgrade repo) to properly update all
those attachment records and be able to finally remove those outdated
images. Note that this may also be fixed without upgrade script if
non-updatable records whose XML declaration is moved out a non-updatable
area become updatable (under discussion with the framework team... we
will see when this lands in master).
Steps to reproduce:
- Install a 16.0 with the website module
- Upgrade to 17.0
- Drag a "Blockquote" snippet on a page
=> Crash and the image is missing (in the DOM but invisible and
impossible to edit). Note that the crash itself will also be fixed by
the later update that will be done to make editor options more robust
to 404 images.
[1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757
opw-3693055
opw-3723895
opw-3744257
opw-3747348
opw-3749764
...
closesodoo/odoo#155015
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_mass_mailing
Since `btn-lg` should only be used for calls to action, this commit
reduces the submit buttons to the normal size to maintain consistency.
task-3097005
Part-of: odoo/odoo#120302
When you create a new website, the contactus page have default action
("Send an Email"). For each action, there are mandatory fields that
cannot be deleted by the user. Unfortunately, the template for the
`/contactus` form didn't have the right fields marked as mandatory.
This led to the following bug:
- Go to `/contactus`
- Edit the page
=> The Email and Subject fields can be deleted. However, when you drop a
form and set the action to "Send an Email", these fields are mandatory
and cannot be deleted. This commit fixes this bug by ensuring that these
fields are marked as mandatory on `/contactus`.
task-3302433
closesodoo/odoo#123360
X-original-commit: 09a9cff6af44157c760c4f3d95d478f10d5c2411
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
With this PR, the `digest_data` template has been changed, so the `digest_tips`
is not compatible with the new changes.
This commit changes the `digest_tips` data to be compatible with the new changes.
Below are the modules affected:
- account
- crm
- digest
- hr_expense
- hr_timesheet
- im_livechat
- mrp
- project
- purchase
- sale_management
- stock
- website
task-2717426
Part-of: odoo/odoo#89549
New text_cover snippet added for the editor. Editors are now able to use
a cover composed of an image and some text on the side.
task-2691555
closesodoo/odoo#105650
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
before this commit, on contact us form, except
question input all the other required input
field has * (asterisk) after the field label.
after this commit, * will be added for the
question input label in the contact us form
closesodoo/odoo#115780
X-original-commit: 127f7f5cfbca103f6d50330aefe355fdaee808c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Cannot be used in v16 since some mixin don't exist anymore.
After 4 odoo versions, and now that we use bootstrap 5, we drop the
support of bs3.
closesodoo/odoo#109359
X-original-commit: 2c34fd4f031b006451305c46b99a790540c5e902
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since [1], the Masonry snippet is in grid mode only and its templates
have been modified to allow this mode. However, some of them don't look
good and have to be improved.
This is what this commit does:
- some text blocks were too small so their height has been increased
- the Masonry second default image has been replaced by another one
that looks better.
[1]: https://github.com/odoo/odoo/commit/85b352af319edec84407f2046cf795b4e5503460
task-3013055
closesodoo/odoo#102984
X-original-commit: ad8926eafd34c2743e1a5247f6171fd183e6e506
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
*: im_livechat, survey, utm, website_crm_iap_reveal, website_forum,
website_livechat, website_sale, website_sale_comparison
Before this commit all cookies were considered essential.
This commit makes some of them optional. It also makes it possible for
the website visitor to only accept the essential cookies.
task-2800976
X-original-commit: 9a8a9463289a7446e9be0ef62ff895feb37a4de4
Part-of: odoo/odoo#101845
Co-authored-by: Benoit Socias <bso@odoo.com>
Short summary:
- People can now use the snippets option to show/hide based on country
- We never use / test / maintain this feature, if it still works since
its introduction 4 years ago that's by luck
- It is probably barely used, we never got a single question or issue
about it
-----------
When we introduced the multi-website feature, it came with 2 main use
cases:
1. Multi website by domain -> Every website has its own domain and based
on that we serve the expected website
2. Multi website by geoip -> Multiple website can have the same domain
and based on GEOIP/country we serve the expected website
We never really supported, highlighted or promoted the geoip case.
We actually never use it ourselves when doing tests, and we don't
consider it when doing specs / improvements.
At most, only a very few people know about it in Odoo.
That GEOIP case is probably not useful at all, as displaying a whole new
website based on lang is not easy since nothing can be shared out of the
box -> Every website has its own COW records.
For instance, one could think of having its main website A and another
website B on which he just added 3 products specific to that website B
country.
But such a case won't even work properly, as any adaption on website A
won't be reflected on website B (design, theme etc).
closesodoo/odoo#99938
Related: odoo/upgrade#3892
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
From [1]:
> Dropped all .badge-* color classes for background utilities
> (e.g., use .bg-primary instead of .badge-primary).
We now have to manage constrast for some badge. It's why we
add 'text-dark' at some point.
Note:
Due to the backport of 'text-bg-#{theme}', we can use this to
avoid to use 'text-dark'.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#badges
Task ID: 2766483
Part-of: odoo/odoo#95450
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closesodoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit add the way to specify the Plausible shared key auth token and
the plausible domain on your website to have the Plausible Dashboard integrated
in your Website > Dashboard > Analytics menu.
Some custom event are already pre-configured as:
Push an event 'Shop' on confirmation on ecommerce (with amount bucket +/- 50)
Push an event 'Lead Generation' on:
'Thank you' page of contactus
Confirmation of subscription for an event
From this way, the end user can just add a goal 'Lead Generation'
or 'Shop' on Plausible to have the Goal values visible.
closesodoo/odoo#91058
Related: odoo/documentation#2007
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Visitors are useful in terms of marketing analysis but they can bloat the
database really quickly if you have a lot of traffic on your website.
This commit aims to relieve the database by fully deleting inactive visitors.
SPECS
On an active website, you can easily reach hundreds or even thousands of
visitors per day.
While active visitors are useful for marketing purposes, inactive ones were
archived after a period of inactivity (i.e: not connected for X days in a row,
where X is configurable as a parameter and 30 by default).
But archiving visitors is not really useful either.
We don't see any specific cases where you would want to restore some visitors.
That means we are better off unlinking the visitors completely to save database
storage space.
We want to make exceptions and avoid deletion of inactive visitors in some
cases:
- When they are linked to a partner (meaning most likely linked to a
registered user)
- When they are linked to leads
- When they are registered to events
Several tests were added to ensure that leads matching these conditions are not
unlinked.
We also took this opportunity to enforce the "_link_to_visitor" rules in those
tests to make sure that:
- When visitors are linked, the leads are merged into the main visitor
- When visitors are linked, the event tickets are merged into the main visitor
- When visitors are linked, the wishlisted tracks are merged into the main
visitor
This is also preliminary work for a commit that will move the push_token of
website.visitors to a separate table.
That will in turn allow us to link the push_tokens within the
"_link_to_visitor" method and delete the linked visitor instead of archiving
it.
LINKS
Task-2410217
Part-of: odoo/odoo#65113
The concept of 'parent_id' on website.visitors was introduced in the saas-13.3
stable while implementing the "event online" feature:
However, it should have been part of the website module from the start since
it's a 'global' concept that does not depend on events at all.
See #53540 for more details.
This commit aims to clean the code by moving the field to the website module,
which allows a nice cleaning of associated overridden methods as well.
Along with that, we move the website.visitor demo data from the event module to
the website module, allowing a fresh install of website to showcase some of our
visitors feature.
We also took this opportunity to do some minor improvements in the visitors
kanban view in order to make relevant information more visible.
Task-2429652
Part-of: odoo/odoo#65113
Before this commit, the behavior disabling the unused snippet assets was put
directly in the autovacuum CRON instead of its own CRON.
That behavior is leading to some perf-issue running the autovacuum cron since
it would take too much time.
Indeed, the code will loop inside as many snippet as it exists, and every time
then perform an SQL Query to get the HTML fields using the snippet.
An improvement will come later to not loop on every snippet anymore.
task-2694120
closesodoo/odoo#79981
X-original-commit: 96ab95d37c9b442a4ccb737fd867ca91ec1c11b6
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In some case, we know that page will contains dynamic content and that cache
should be ignored.
E.g. as soon as a s_snippet_form will be present in page, we know that we need
the real csrf, and so we cannot use the cached response from another user.
Now, we disable the cache (cache_time=0)
closesodoo/odoo#77935
X-original-commit: 262499a91cc9f2365cf2ff131796d9b61b438f9b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Add an option in the masonry snippet's allowing to choose among multiple
templates for the snippet layout. The usability of the snippet also has
been reviewed (restrict the ability to control background on deeper
boxes). Also reviewed the bg-200 use on boxes and replaced them with
a preset as otherwise it seems buggy to not be able to remove the
bg-200 by selecting a preset (other than hitting the trash icon in the
colorpicker).
Part of https://github.com/odoo/odoo/pull/67361
task-2463033
closesodoo/odoo#67361
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: smottet <oms@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
The configurator takes care of the organization of the links to the different
pages. Some links are put in the menu and some are put in the footer. The order
is predefined. If too many links are present in the menu then a sub-menu 'Company'
is created and some links are put in it. For the 'News' and 'Succes Stories' features
a website specific blog is created.
Links have the following order in the menu and are present only if their corresponding
website.configurator.feature has been selected in the configurator excepted for the 'Home'
and 'Contact us' links which are default links:
- 'Home'
- 'Shop'
- 'Event'
- 'Courses'
- 'Services'
- 'Pricing'
- 'Company': if more than 8 links in menu and more than 1 item in this submenu
otherwise the three following links are in the top menu.
- 'News'
- 'Success Stories'
- 'About us'
- 'Appointment'
- 'Contact us'
Links in footer:
- 'Privacy Policy'
- 'Help': if website_helpdesk installed. This is not a website.configurator.feature.
- 'Forum'
Community: https://github.com/odoo/odoo/pull/71993
Enterprise: https://github.com/odoo/enterprise/pull/18930
task-2518565
Co-authored-by: Sébastien Mottet (oms) <oms@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
- fixed xml data files order, otherwise form field would not be whitelisted,
including `email_to`, so the mail would not be send.
- add the same data-for behavior from website_crm to website, to be able to
prefill a field with an URL param
- removed the fallback data-for in website_crm, the JS in now in charge of
doing that. Plus it was creating a misheavior -> you could have prefill set
to false but still, it would prefill the user info
- fixed the form option so the field.name is not used as field.string if there
is already an explicitely set field.string..
- adapt field name in /contactus form (xml view), form snippet (registry) and
crm form (registry) for more consistence
- added the prefill option set to true by default on /contactus (to fit what
we had before). This came with a change in the test as we don't need to
enable it anymore.
- added also the prefill option to true by default on form snippet
Part of #69888
task-2462993
Before this commit (and the previous ones that prepare it), the contact
us page was largely editable but not entirely. The automatic address
field on the right column prevented the page to be considered like any
other page and only the left column was editable. That led to less
possibilities and difficulties to make a modern contact page.
Now, the whole page is static, like a page the user would have created
himself. Same for the thank you page. This comes with the disadvantage
of having to handle the address by yourself (but that's not a field that
would normally change a lot anyway) and the website_crm app now needs to
be enabled on the form via edit mode after install to change the form
action to lead creations.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
*: website_crm, website_form_project, website_hr_recruitment,
website_sale
Replace website_crm specific behavior by another option for all website
forms.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
*: crm_iap_lead_website, website_crm, website_form_project,
website_hr_recruitment, website_sale
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
Rename field website_type_preselection to website_config_preselection since feature
preselection is not only based on website type anymore but also on website purpose.
task-2518565
closesodoo/odoo#73377
Related: odoo/enterprise#19498
Related: odoo/upgrade#2625
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Creating a website through the configurator activated the configurator tour.
This tour was active for every websites even the ones not created using the
configurator. Theme tours were overridden by the configurator tour when they
should have been the active tour for website not created using the configurator.
Now the configurator tour is an asset specific to each website. This asset is
deactivated by default and activated for a website only if it is created using
the configurator.
- Some actions of the website tour were also visible when we were not in edit
mode. extra_trigger has been added on these actions to ensure they are visible
only in edit mode.
task-2518565
closesodoo/odoo#72827
X-original-commit: 5799410ec257fc7f756722579d3d0141b0ce7de4
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- The selection of cards corresponding to already installed modules
is disabled. A disabled style has been applied to these cards and an
info icon added. On hover on this icon the user is informed that the
module is already installed on its DB.
- Modules that were preselected based on website type can now be
unselected by the user.
- Correct typo in description of feature_module_career.
task-2518565
closesodoo/odoo#72688
X-original-commit: ab364b06dbb20cce90c7caa8ca15d034e2dcb25e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
- New and multiples pictures
- Empty URL instead of odoo.com by default
task-2471323
closesodoo/odoo#70528
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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
Some feature descriptions and titles have been reworded.
A sentence has been added below the title to indicate
that choices made on this screen are not definitive.
Task ID: 2451965
closesodoo/odoo#70252
X-original-commit: 63195ba03ccc1bf40b4682fc7c9aa4a1a55f1e43
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Elisabeth Dickinson