If you create an issue when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create an issue directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created issue. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the issue, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
When no stage has been defined for a project, the new issues are
set in an undefined stage(stage_id = False). Then these issues must
be counted.
opw:676985
If an issue is created without default stage, it is not counted in the
total of issues. However, a task without default stage is counted (see
commit 432c01c0).
Fixes#11398
opw-672380
When using the mailgateway, the responsible of the newly created lead / applicant /
issue is explicitely set to False since the original mailgateway commit in 2010.
However this conflicts with some custom behavior that tries to set the responsible
on the same objects. Notably in recruitment the responsible is set to be the
recruitment responsible set on the job, if any.
In this commit we replace the explicit set of user_id=False to using a
default_user_id=False in the context. This way the admin or mailgateway user
will not be responsible of every new records. And this enables custom behavior
to find a responsible.
Some computed fields have been added in v9 and are calling the method
_compute_day. This method accesses the project related to the issue
So a user portal is able to see his own issue, but cannot open the
form view as the prefetching is loading the fields. Hiding them in
the group base.group_user doesn't have any effect as the compute method
is called on the read. These information may have their importance to
the customer too.
We decided to compute these fields on superuser access rights.
Also the field project_id is displayed on the project_issue form view.
As this information is internal, we're hiding this also under the employee
group.
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
If an issue project is changed, depending if the destination project has
a set partner ("Customer") or not:
- if set, the project issue partner will be set accordingly
- otherway the potentially set partner will be conserved
Since 3fe06da if the project had not partner, the partner was unset
which is undesired.
Commit bb1200adc7 introduced the automatic
addition of cc as followers of tasks and issues. However it seems to
automatically create partners if the address it not recognized. This
does not seem a good idea.
project.task: use an onchange to update date_start when changing user_id.
Indeed date_start is automatically updated in the create / write. Without
the onchange, this may lead to errors related to date_start being greater
then date_end.
project.issue: code in create and write now takes into account date_open
values given to the method and avoid erasing them.
In issue however the onchange is not added. Indeed the date_open and
date_closed fields are not visible in the view. They are automatically
computed and used to compute statistics.
When choosing use tasks / use issues, correctly update the project alias. Indeed
only the use issues checkbox had an onchange. This revision adds the onchange
on use tasks so that the method correctly computes the new alias destination model.
Also updated the _get_alias_models method to be more modular instead of hardcoding
values. Call super.
Coming from hr_recruitment, where kanban_state is displayed, but without the customization
Also, remove lingering options in view, and missing fields for project_issue
Main addons updated :
- crm: Conversion and Won / Lost actions
- hr_holidays: Approve / Refuse for hr users / officers
- project: Assign / New (task and issues)
- forum, website_project_issue, website_portal_sale: go to the
website view
concept of default / common stages.
However as the link between stages and projects is still a many2many
it is still possible to have shared columns. It is however not the
standard way of using stages.
- 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
This fix sets the first sales team of the current user as the default sales
team if no other one is given.
For models: crm.lead, crm.phonecall, crm.claim, crm.helpdesk,
project.issue, sale.order, account.invoice
Existing methods are removed and new methods in sales team model
(crm.team) have to be called when needed.
closes#6438
opw-633562
to message_add_suggested_recipient; signature has been updated when migrating to the
new API, removing an argument that is now contained in self. However all addons were
not updated accordingly.
- Several Modules have been splitted into several apps
Examples :
Human Resources : Splitted into Leaves, Recruitment, Expenses, Appraisals, Timesheets, Employees, Payroll
Marketing : Mass Mailing, Events, ...
Messaging : Chat, Agenda, Notes, Address Book, ...
- Generally, the related reports have been moved in the apps, as last menu
- Also, configuration menu (no_one group) have been moved into a config root menu
exception made for the warehouse and lunch modules
- Configuration for typical frontend modules have been moved into the website settings
Related modules : Ecommerce, blog, slides, forum
- When they are present, menus like 'product' or 'customers' have been moved
ex : Customers in Sales menu, Product in POS menu
- A lot of sequences and xmlids have been added or modified in this commit
- List of apps :
1 Chat : Inbox, Channels
2 Agenda : Calendar
3 Notes
4 Address Book : The view contact is still laying in the mail module (1 app => 2 icons)
5 eCommerce : Still to define : Config + Orders Analysis + Shipping + incoming Amazon module
6 Sales : Dashboard (Sales Team Kanban), CRM, Sales (note that they are splitted into 2 submenus)
Assignation, After-Sales (Invoicing and Services), Reports
7 Point of Sale : Dashboard (POS status), Orders, Reports
8 Project : Dashboard (Project Kanban), Search (all tasks, issues), Incoming Forecasts module, Reports
Project.issue.version feature has been removed completely
9 Members : Dashboard (Members Kanban), Report, Config
10 Timesheets : Time Tracking, Approvals, Reports
11 Purchase : Purchase, Control (Products and Bills)
12 Warehouse : Dashboard (Warehouse Kanban), Operations, Inventory Control, Schedulers, Configuration
13 Manufacturing : Same menu structure
14 Mass Mailing : Mailings, Campaigns, Reports
15 Events : Events, Reports
16 Lead Automation : Campaigns, Reports
17 Surveys : Surveys, Reports
18 Human Resources : Dashboard (Departments Kanban), Employees, Contracts, Engagement (Gamification)
19 Recruitment : Job Positions, Applications, Resumes & Letters, Reports
20 Expenses : Expenses, Approvals, Reports
21 Leaves : My Leaves, Approvals, Reports
22 Appraisals : Appraisals, Interview, Reports --> Will probably be modified by the incoming refactoring
23 Payroll : Current Menu
24 Lunch : My Lunch, Manager, Configuration
25 Accounting : Same menus currently, waiting the new accounting to be merged
26 Fleet : Current menu
27 Sign : Incoming docusign module
28 No root menuitem with this sequence
29 Attendance : Attendance, Reports
Sign in/out by project feature has been removed completely
30 Link Tracker (group_no_one) : Link Tracker, UTMs
New view added : URL Shortner, which is the frontend view embedded in backend
31 Versionning : Website domain, Versions, Experiments
32 Slides (group_no_one) : Channels, Categories, Slides, Tags
33 No root menu item with this sequence
34 Livechat : Channels, History, Reports
35 Dashboards : My Boards, Configuration
36 App Store : Local Modules, Apps, Updates
Last Settings : Incoming Dashboard Settings, Sales, ...., Website Settings
General Pattern for all modules' settings :
| Module_name
|-- Settings : General Config view (checkbox screen)
|-- Record setting 1
|-- ...
|-- Record setting n
Example for Sale module
| Sales
|-- Settings : Checkbox screen
|-- Quotations
|---- Quotation Templates
|---- Report Layout Categories
|---- Contract Template
|---- Invoice Type
|-- Contract
|---- Deduplicate Contacts
|-- Delivery
|---- Delivery Methods
|---- Delivery Pricelist
_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.
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
- stage model (project.task.type): add fields holding the eventual specific
legends for kanban states and star (priority) management
- project: task now have labels; you may use project to hold trainings
instead of tasks.
- project form: use label field on tasks statinfo to use the label
- project.task form: use kanban state customization using states_legend option;
- project.task kanban: use kanban column and kanban state cuztomization
using group_by_tooltip and states_legend options
- project_issue: issues now have labels, like tasks.
- issue: same kanban custo as for tasks
- update data and demo data
[IMP] web: statinfo widget now take an optional label_field option allowing
to have strings coming from another field present in the form view
Simon Lejeune