As this category is used by `hr` module, we need to ensure the records
exists in database.
Even if the xmlid is automatically created if not present, it may be
deleted during upgrade (migration) if noupdate flag is not set in
database.
Purpose
=======
Currently, as the admin as no email address, it's now impossible to install
the mail module without demo data, because of the following data:
<record model="mail.message" id="module_install_notification" context="{'mail_notify_noemail': True}">
<field name="model">mail.channel</field>
<field name="res_id" ref="mail.channel_all_employees"/>
<field name="message_type">email</field>
<field name="subtype_id" ref="mail.mt_comment"/>
<field name="subject">Welcome to Odoo!</field>
<field name="body"><![CDATA[<p>Welcome to the #general channel.</p>
<p>This channel is accessible to all users to <b>easily share company information</b>.</p>]]></field>
</record>
Because when creating a mail.message a user error is raised if no email address is found.
@api.model
def _get_default_from(self):
if self.env.user.email:
return formataddr((self.env.user.name, self.env.user.email))
raise UserError(_("Unable to post message, please configure the sender's email address."))
In a general way, all the users should have an email address.
Purpose
=======
Currently, as the admin as no email address, it's now impossible to install
the mail module without demo data, because of the following data:
<record model="mail.message" id="module_install_notification" context="{'mail_notify_noemail': True}">
<field name="model">mail.channel</field>
<field name="res_id" ref="mail.channel_all_employees"/>
<field name="message_type">email</field>
<field name="subtype_id" ref="mail.mt_comment"/>
<field name="subject">Welcome to Odoo!</field>
<field name="body"><![CDATA[<p>Welcome to the #general channel.</p>
<p>This channel is accessible to all users to <b>easily share company information</b>.</p>]]></field>
</record>
Because when creating a mail.message a user error is raised if no email address is found.
@api.model
def _get_default_from(self):
if self.env.user.email:
return formataddr((self.env.user.name, self.env.user.email))
raise UserError(_("Unable to post message, please configure the sender's email address."))
In a general way, all the users should have an email address.
It doesn't exists anymore in enterprise version.
Combinaison of website_publish , website_page, and multi website allow to
partially replace it.
AB testing will be back in a later version after a big refactoring.
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
Before this rev. one could set the report layout on the company using a
hardcoded list (background, clean, standard, etc.). Other modules (typically
accounting modules) could add options in this list. The used template was built
on the layout key.
Now, the layout is a many2one field to a newly created model `report.layout`,
which is linked to a view with the layout architecture.
This gives more control to customize reports and create a new layout (without
creating a python module that extend the layout selection).
מזל טוב
The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.
Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily
Adapt the css and views to be easier to switch direction
Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language
add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY
[NEW] base: show enterprise module, with an 'upgrade' button
[IMP] *: some modules renaming, and improved copywriting of manifest
[IMP] *: utm on links to odoo.com
- Update all the pictures
- Rename the partners with a name that is easy to say for an English speaker (No more 'Agwoleight')
- Update all the addresses/phone numbers in the american format
- Unify the demo data with the new theme (Wood shop/manufacture,...)
Use a new view to choose the document template.
Remove layout fields from base company form.
Reword Edit Header -> Edit Layout
Set a default logo for a new company in data instead of demo data
task: 60668
Task 1856935
Currently, if installing a module's demo data fails (because the
module was uninstalled and some were left over and can't be
reinstalled, or because they're broken, or…) the installation of the
module fails and further installations are skipped (?).
Since demo data are non-essential (though required to run tests),
rather than fail everything if they fail just roll them back and
notify the user.
This change generates a warning log *and* shows a notification popup
to the end user.
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
* store hashed passwords in the `password` column but gate it behind a
computed field
* make the password field essentially write-only (SQL aside)
* add a "plaintext" hash type so it's possible to set the password in
SQL directly & be able to login & have it automatically updated
Task 34211
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
localhost mailserver effectively blocks the server wide smtp setting and
almost never is a sensible default in any kind of deployment.
If you just deploy an instance with smtp setting, so that you can start
inviting users without caring about mail integration so far, then this
setting does produce unexpected and awkward results.
Closes#22790 and task ID 1830779.
create_date is not required but may be assumed as always set such as in
base.partner.merge comparison
The administrator had no create_date set
Avoid errors in merge wizard if one of the record has no create_date
Fixes#22730
Christophe Simonis