Before this commit, we executed the request even when creating a new
badge. And it thrown a traceback.
After this commit, we return default values before executing the
request if this is a new badge.
task-2312878
closesodoo/odoo#60441
X-original-commit: 85995b7a4f0544779f3de537f0e6024820abbd5d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
There is no field 'ids' on a gamification.goal, but one called 'id'
Without this commit, calling _get_serialized_challenge_lines (or
indirectly, calling report_progress) with a non-empty subset_goals was
failing due to an invalid domain.
This is not supposed to happen on standard flow but can be triggered
with manual modification of date fields and refreshing a challenge.
Fixesodoo/odoo#25913closesodoo/odoo#54387
X-original-commit: 1e3483d2fc99763940396936758cf99b14d0a118
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
This commit improve the tree and form view of gamification.karma.rank
and correct a bug on auto generated email when a user pass to the
next rank.
- Add a stat button in form view and column in tree view to know
how many users have the current rank
- Split Description and Motivational in 2 pages
- Hide the line that mention the next rank the user can get when
there is no more rank to get in email templates
- Add a menu to access badges tree view
Part of https://github.com/odoo/odoo/pull/46634
task-2201708
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Before this commit, when checking the gained karma per month or per week in
/profile/users route, the users gained more karma than they actually have.
This is due to the way demo data are loaded : karma tracking history is added
but when the final karma is set on the user, a new line of karma tracking is
created on the DB (via write or create method). But as the transaction with
karma tracking demo data is not commited yet, the old value is still 0.
That leads to add a new karma tracking line that have old_value = 0 and
new_value = user.karma. At the end the users 'gained' as addition the amount
of the karma they have.
E.g : Mitchell Admin has 2500 karma and his karma tracking history is the
following: 0 -> 1000 then 1000 -> 1500 then 1500 -> 2500.
In total, Mitchell should have gained 2500 XP: (2500-1500)+(1500-1000)+(1000-0)
But, before this commit, as there is an additional 0 to 2500 karma tracking
line, Mitchell Admin gain in total : (2500-0)+(2500-1500)+(1500-1000)+(1000-0)
= 5000 karma.
This commit clean that additional karma tracking line to get a correct karma
tracking history.
Task ID: 2209743
PR #48042closesodoo/odoo#48061
X-original-commit: 858f80e2529b17d1857d77f372c378ae235443de
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
In various views, the min width of some columns is too short for the label of
the field. This task aims at fixing this by increasing some minimal widths
and relabeling some fields.
SPECIFICATIONS
crm
* in view_crm_lead2opportunity_partner_mass, view_crm_lead2opportunity_partner
add date widget on create_date and remove the phone field in the inline
treeview of opportunity_ids;
event
* in view_event_form set width of boolean field 'done' to 70px and in
view_event_mail_tree set string of field 'mail_sent' to 'Sent'
* in view_event_form_inherit_ticket set string of fields seats_max to
'Maximum', seats_reserved to 'Reserved', seats_unconfirmed to 'Unconfirmed'
and set width '100px' in the inline treeview of event_ticket_ids;
gamification
* in challenge_line_list_view and challenge_form_view set string of field
'target_goal' to 'Target' in the tree view and inline treeview of line_ids
LINKS
Task ID 2166865
PR #43401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.
In this commit we
* remove unnecessary code examples in gamification about followers: using
that model as example of code for goals is probably not a good idea as it
is technical;
* rewrite routes called by JS are simplified to better match JS
implementation;
* introduce computed fields to fetch related partner or channel name,
email (partner only) and active status;
LINKS
Task 1933771
Task 2078313
closesodoo/odoo#39808
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
We are initializing over the limit to make sure we will compute it at least once.
If the target goal is set to 0, we are facing a division by zero error when
displaying the gamification goal just after initialization.
closesodoo/odoo#40735
X-original-commit: 24546e7c4cac61efea8d3f9e558518a55ef9acd2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit adds a section to distinguish the certification badges from the
other badges users may obtain in eLearning. Certification badges are available
on the ranks page, linked to a running survey. Clicking on them directly
redirects into the linked course.
Task ID : 1961053
PR #32594
In this commit we rename stat_count into granted_count, and stat_count_distinct
into granted_users_count to reflect more what are those variables, aka count
of granted badges.
Task ID: 1961053
PR #32594
The karma field has been removed with this PR #35587 but before it
was displayed in the res_users form view through the website_forum
addon under the name "Forum Karma". This task adds it directly in
the gamification inherited view for more consistency.
Task ID : 2116759
closesodoo/odoo#40316
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
This is the first huge step to improve the test suite in several ways:
- Make them demo data independent, allowing to modify the demo data without having to adapt the tests depending on it. It also allows to have a beautiful + convenient demo dataset to make a demonstration, and to configure complex data in the tests to manage the corner cases.
- Improve the test performances by converting them into SavepointCase. Each test will be rollbacked to it's initial state, after the setUpClass call. That way the different data are not re-created at each test for nothing.
- Introduce several test classes in base/tests/common.py to launch a TransactionCase, HttpCase or SavepointCase test with an available demo user, portal user or a large set of partners.
- This is the first step to tend to a rolling release process, allowing to execute the tests (or a subset of the tests) on a migrated base, for example.
closesodoo/odoo#39868
Taskid: 2075739
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit adds a SQL constraint to force the min_karma of the gamification.karma.rank model to be
above 0.
A karma_min set to 0 (or lower) could create some frontend issues when displaying required karma.
PR #39870
Task#2032649
The return type of the _get_next_rank method on the 'res.users' model was inconsistent.
It sometimes returned a recordset, sometimes False.
This commit adapts the method to always return a recordset (which is empty for the previously
'False' case).
This is a preliminary work for the level up animation on website_slides task.
PR #39870
Task#2032649
Purpose is to have all karma related tests in the same file to ease finding
them back. Some tweaking is also done like using a savepoint case and ensuring
tests can always be re-run.
LINKS
Task ID 2003505
PR #34594
Purpose is to support both search term and karma gain group by in the
URL, using keep_query.
Clean some code and move karma computation to res.users model to avoid
having sql in controllers.
Also fix some display issues.
LINKS
Task ID 2003505
PR #34594
PURPOSE
Allow karma gain tracking enabling notably display of top users based on
weekly / monthly gain in website profile.
SPECIFCIATIONS
Each time a user gains karma a record is created in the gamification karma
tracking model. Scheduled activity runs to consolidate the records into
monthly gain records to avoid having crowdy table and unnecessary noise
in karma gain.
This model is made private and only accessible through some dedicated
compute methods / controllers used in website profile.
In website profile module buttons are added to see users ranking based
on their total karma (like before) but also by last week and last month
gains (using the newly introduced tracking model).
LINKS
Task ID 2003505
PR #34594
Martin Trigaux