This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Purpose
=======
Allow to restrict note to users having access to a specific company
For example, when creating a new company, it create a "Useful Links" note
that is used on the payroll dashboard (With granted access to payroll officers
who belongs to this company).
This note should be restricted to people having access to the company,
and shouldn't be mixed all the time for people having multi company accesses.
closesodoo/odoo#84155
Related: odoo/enterprise#24128
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The view is broken because read_progress_bar() calls read_group() with
two groupbys in eager mode. The method read_group() is overridden for
model `note.note` and does not handle that case: the returned result is
incorrect. We modify the override to call the default read_group() in
that case, which eventually fails and makes read_progress_bar() fall
back on its naive implementation.
closesodoo/odoo#73839
X-original-commit: 6443e22feea914639f143a94a802b52a74a8ce19
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``message_channel_ids`` field from ``mail.thread``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to access them. We can now safely remove this field as it
has no use anymore.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
- Have a standard V13 with note
- Connect as Admin A
- Create User U1 and U2 with password and email on partner
- As A, create a note N
- Add U1 as a follower
- Login as U1
- Open N and add U2 as a follower
We have a custom record rule that provide access to notes if
you are in the "message_partner_ids" of the Notes.
An override to the field in notes to compute as sudo fix the issue
opw-2223632
closesodoo/odoo#51082
X-original-commit: e1fbac466ff6c3abfd0de5760f43a3ff2e5cdb90
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
UI improvement:
If there is no stage then there will be no button(no status bar) but there will be stages but task or note etc.. will not be in any stage then there will be 'undefined' so by click on that ('undefined') user can move to any stages. To avoid this behavior we add a default stage in note.
Also:
- Don't display "Active -> True" when we create a note
- Allow to create tags on the fly on a note form view
When user create a new Note or click on 'Tick' option in kanban view, remove the message 'Active->True' & 'True->False' and Make the creation of 'Tags' inline mode.
[IMP] note: 'Tags' should be created from note's form view.
As this button leads to a void form view without context it is not
really usefull. As creating new records is achieved using aliases
there is no real need for a New Task/Issue/Note button.
mail/new controller is kept for compatibility but should be removed
before v11.
There is now a single method easier to inherit to add specific behavior
for the display of access button as well as actions buttons. All addons
using this mechanism are updated accordingly.
stage_id is comptued and based on stage_ids
The default value should be put on stage_ids, not stage_id, it has the same
effect but avoids an unecessary chain update.
Fabien Pinckaers