- Connect as a user with only 'User' rights on projects
- Set a project as favorite (click the star)
The project is not set as favorite.
Since only project managers are allowed to write on projects, the field
`is_favorite` is set as read-only. Therefore, it is filtered out by
`_generateChanges`, and nothing happens.
First step is to set the attribute `force_save` in the view, so the RPC
`write` call is forced. Second step is to compute directly the inverse
thus bypassing access rights.
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
opw-814604
opw-801587
closes#22938
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.
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
* crm, project, website, website_event, website_blog, website_forum,
website_sale
Eg: the tour 'shop_buy_product' is extended by the website_sale_options
addons to add a step to close a modal.
The current solution was requiring the module that defines the tour
to extend, then add/remove steps in the "step" key of the tour
definition.
Some of the problems with this method were:
* The "register" method calls the "update" method to immediately
search for tip to place once registered (as register may be called
after the DOM is ready). So extensions of tours were happening after
the tours were started (and the tours were not restarted).
* The addition/removal of steps was happening after they were filtered
according to the "edition" key.
To allow extension, the system is changed as follow:
* The "register" method now only saves the steps and options without
modifying them and does not call the "update" method.
* Once the DOM was ready, the tour service started listening to DOM
mutations and called the "update" tour method. Now, this "update" call
is replaced by a "_register_all" call, on DOM ready and at the end of
the current call stack (which makes sure all modules are loaded). This
"_register_all" method marks the registered tours as ready after having
filtered the steps according to the "edition" key and initialized the
current step to trigger.
* Also, tours can now define a "wait_for" option which allow them to
be marked as ready for run and update after the given deferred. Those
tours can now also be extended without having to wait for the deferred.
PhamtomJS must wait for the "ready" key to be true to run the tour.
Split project to move portal features to a new module named website_project.
Portal users may now access their projects and tasks throught the
website_portal My account page. The Backend portal menuitem is removed.
Simplify the privacy settings of project, to be visible to portal users the
project must be in 'portal' mode.
Original authors: Vipul Bhatt, Florian Wintjens
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
[REM] portal_project: move ALL the things
- move portal access rights from portal_project and website_project_issue to project and project_issue
- move portal menuitems back to their respective module
- remove public visibility of projects
- adapt demo data to have a 'Demo Portal' project
- add correct access rights for account.analytic.line for portal users
- small view tweak (do not display 'timesheet' tab if one can't see antyhing in it anyway)
code in resource and project.
This library was once used to perfom resource allocation: scheduling
tasks and things like that. However this feature cannot be accessed
through the interface since a long time.
The feature is now removed from the project code. The library has been
removed. Some code in resource used only in the project code
has also been removed, as well as a test linked to this code.
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
tests.
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
- remove unnecessary copy() method from project/res_partner.py
- remove old methods on project.project
- progress is not used anymore on project.project
- use clickable statusbar for project states
- remove _resolve_project_id_from_context
- rename project.category becomes project.tag to be more explicit
- remove old methods on tasks
- issues: remove option fetchmail_issue
Tests have been migrated to the new api to prepare the migration of the
mail module itself. Moreover tests have been cleaned: redundant tests
and unnecessary tests have been removed.
As the base test class in mail is used in other addons, other addons
have been updated :
- portal
- project
- portal_project
- website_project_issue
- sale
- purchase
Future commits will come with somes fixes for issues detected when cleaning
the tests.
_track is now a method that returns the subtype to trigger in a given
tracking context. A tracking will now lead to only one subtype
being trigerred, instead of having multiple possible subtypes.
Now, one tracking leads to one message with one subtype, or without subtype
if there is none matching. This simplifies the model for future evolution of
chatter and mail.
[IMP] project, project_issue: cleaned task and issue subtypes, now having
opened for created / assigned.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Replaced some read by browse
Moved get_reply_to from mail_mail to mail_message
Hint: specifying email_from, reply_to help to enhance computation time
[REF] mail: cleaned some tests, renamed a file, moved mail_group tests into a dedicated file
bzr revid: tde@openerp.com-20130827133058-ko0g0ib0f0jihmdk
Nicolas Martinelli