Companies now always have a default calendar configured. All methods in
resource module should therefore be able to use a real resource.calendar.
This commit removes the computation based on a pseudo 8-17 calendar
given as weird method parameters.
Project is updated in order to use the company calendar by default.
When subscribing to a project, an user is also subscribe to all existing
living tasks. Active is defined as active tasks not in a folded stage.
As requested.
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
Purpose
=======
External links in the data sometimes open in the same tab, the users loses times as he has to come back (and looses the context).
Specification
=============
Any external links in data (planners, settings) should open in new tabs.
The 'Start here to discover Odoo' is a data to help users to use Odoo.
Once they have understood, user often delete it but it comes back after an
update. The only way was to archive a record.
Using forcecreate is another way to avoid recreating it after an update.
Fixes#15262
These links are links to the Website live chat app description,
not our actual livechat support.
Besides, we currently do not make support through the
livechat.
opw-705614
Remove unused fields (including inherited view) in kanban project view,
For example, `user_id` triggers a read for each project on res partner,
40 projects display = 40 read on `res.partner`.
Closes#15096
Related to opw-696979
In 3041efb, it was introduced a partner_id reset when project_id is
False, but this causes you can't apply default values to partner_id
directly.
One use case where happens:
* Go to Sales > Customers.
* Select one customer.
* Click on the smart-button "Tasks".
* Create new task.
Before this commit, the customer where you come from is assigned.
After this, no partner is selected.
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
First step towards cleaning and improving automated actions is to
correctly name things. base_action_rule module is therefore renamed
to base_automation. Model is also renamed to base.automation.
Remove unrestricted "read" access. To make code internally using `ir.model`
work, add a private method `_get` on `ir.model` to retrieve the record
corresponding to a model name, without access rights issue.
Change signature of method `get_authorized_fields` to make it use a model name
instead of a model id. This removes the necessity of a search on `ir.model`.
Christophe Simonis