PURPOSE
This commit globally improves the backend survey module usability, notably by
renaming labels, moving menu items around and cleaning unused features.
SPECIFICATIONS
These changes include (non-exhaustive list):
On questions
- Changing labels, action helpers and modules description to be clearer;
- Re-organizing the survey.question form view, notably to clearly distinguish
fields related to answers and validation options;
- Removing the "Clean test answers" server action as it can be done through
a search + unlink;
- Removing the allow_value_image field as we now always display the
image field. Users simply choose to let it blank;
On surveys
- Re-organizing the survey.survey form view fields to get a clear view of
the various options;
- automatically update scoring type when checking certification: if not one
linked to scoring, update to scoring without answers;
- set create as create_multi to speedup batch creation;
- Changes ACL rights for user_input_line. Now, only Survey Managers can
change answers. Survey users keep only a read access on answers, meaning
changing what customers / people answered is now limited to managers;
Globally
- Moving menu items and make them visible outside debug mode;
- Answer recap on print frontend page is now visible whenever a scoring is
applied, not only for certification, as if scoring is activated seeing
answers is probably wanted;
Task-2600241
closesodoo/odoo#79813
Related: odoo/upgrade#3033
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@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
PURPOSE
As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.
SPECIFICATIONS
Main user answer model is ``survey.user_input``. It holds lines related to
answers given to specific questions. In this commit we rename this model from
``survey.user_input_line`` to ``survey.user_input.line`` to be coherent with
general odoo naming guidelines.
LINKS
[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
PR #40765
PURPOSE
As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.
SPECIFICATIONS
In this commit we rename the long standing ``survey.label`` model. Indeed
a label is something before a question, like an input label. Labels in survey
are used for suggested answers and sometimes as rows for matrix answers.
After much thoughts we rename ``survey.label`` to ``survey.question.answer``.
It indicates this model holds answers. Moreover it is namespaced within the
``survey.question`` model name to avoid conflict with user input / user answer
model.
As model naming changes, some fields also evolve. In survey.question model
* ``labels_id`` is renamed to ``suggested_answer_ids`` to indicate it is
used to display suggested values to the user;
* ``labels_id_2`` is renamed to ``matrix_row_ids`` to indicate it is used
to generate the rows of the matrix-type question. A matrix is therefore
done using ``matrix_row_ids`` for rows and ``suggested_answer_ids`` for
columns which seems easier to understand;
In survey.question.answer (old survey.label) model
* ``question_id_2`` is renamed to ``matrix_question_id`` to ease its
understanding, notably that it is used for matrix questions;
LINKS
[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
PR #40765
This commit allow gaining a badge at the end of a certification survey if succeeded.
The badge can be configured on the survey if the certification mode is activated.
The badge is linked directly to the survey and not the challenge,
because it makes more sense to configure directly the reward on the survey and
not the way to gain this reward. As the way is always the same.
Only one badge can be set on the certification survey.
Only the name, description, image and badge level can be configured.
The rest of badge configuration is automatically set to correspond to the use case.
When a badge is configured on a certification survey, the needed challange, goal
and challenge line are autogenerated.
The badge is available on the user's profile page if he gained it.
Once the badge is configured on the survey, he cannot be changed
(remove + create new one), only modified (badge attributes edition).
The only way to remove the badge is to uncheck 'certification_give_badge'.
When removing the badge from the certification survey, all the autogenerated
records (at badge creation) are deleted to avoid ghost records (as they have
no purpose outside of this context). If the badge is owned by someone, the badge
is only archived. If nobody owns the badge, the badge is deleted.
Survey users now have the right to create badges but not challenges or goals.
All the autogenerated records are handled in sudo, to allow the survey user
to configure a badge on their survey.
Note : To avoid having to rewrite the complete context in an xpath expression
only to display the certification badge on the user's profile page,
the default website_published value of the certification badge is defined
directly in the survey module even if survey does not depend of website.
This attribute will be ignored until website module is installed.
Task ID : 1935136
Closes PR #31486
Stages modification through the clickable statusbar wasn't very intuitive.
By fixing default behavior through states (and corresponding buttons), default user experience is simplified.
3 static states available : draft, open, closed
Form view: navigation through states with buttons
Kanban view: disabled modification of survey state
Task ID : 1949110
closesodoo/odoo#32325
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
Task #1902306
Purpose
=======
survey.question is now also the model used for the survey's pages (with the "is_page" field set to True).
This allows to put all the pages and questions together in a o2m field on the view side and
easily reorganize your survey by dragging the items around.
It also removes one level of encoding by directly having 'Add a page' and 'Add a question'
links on the tree view of questions, enabling a faster encoding.
However, this has the downside of making the code reading a little bit more complicated.
Efforts were made at the model level to create computed fields so that the use of these models
still seems somewhat logical. That means:
- A survey still has "page_ids" (question_and_page_ids filtered on is_page = True)
- These "page_ids" still have question_ids (questions located between this page and the next)
- These "question_ids" still have a "page_id"
That makes the use and display of these information at view and controller levels easier to understand.
The rule "survey_stage_rule_survey_user_read" was applied on the model
"survey.model_survey_page" instead of "survey.model_survey_stage".
closesodoo/odoo#30342
Purpose of this commit is to rewrite all access rights and rules of survey
models. Indeed this module is quite old and rules may give some strange
permissions to some people and does not enforce the use of real survey
user groups.
Specifications
* survey manager: can CRUD everything;
* survey users: can CRUD their own surveys, read all;
* regular users: cannot access anything and will use dedicated controllers
and routes;
* portal, public: cannot access anything and will use dedicated controllers
and routes;
This commit alone breaks some use of survey, notably its embedded portal.
Future commit will update code to use those new ACLs. It is done in several
commits in order to have smaller diff and avoid having too large diff in a
single commit.
This commit is linked to task ID 1911586 and PR #28986.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights
when created from the dashboard, which was leading to an error.
This bug leaded to a new discussion. Better to have basic employee having user
rights for all main applications. For bigger entreprises there is an admin that
will carefully remove extra rights, if necessary. The target is small businesses,
it makes sense that every way to create a user gives the same result.
In conclusion, each new user has a full access to the applications by default
How is it implemented ?
We added an inactive default user which original access right to the groups
'base.group_user' and 'base.group_partner_manager' in base. Each
application will extend the default user's access right by adding the maximal
access right for this application.
On user creation, we will use by default the 'group_id' field from the default
user. We will in the same time remove the ugly 'default_groups_ref' key which
was passed sometimes in the context for some fields in some views, and sometimes
nothing.
So, the user can modify the access rights for the default user, but he should be
aware that removing project user access rights for a default user will prevent
a *created on the fly in a task* user will not be able to access the task.
Allow the partner associated to a survey user input to read the data on
this output.
A survey can be created by a different user than the one
filling it, for example an appraisal interview request can be created by
another user than its interviewer. In this case if the interviewer is
not Survey / Manager an error would happen.
closes#7978
opw-644791
wde-odoo