This will prevent various flicker when using previous/next.
task-2243518
closesodoo/odoo#59411
X-original-commit: 415683c575c1b6ce3e0591a65df20d687790dd18
Related: odoo/enterprise#13885
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Added a new tour for the module hr_recruitment
Hr.job:
Form view:
- Using a notebook view for increased clarity
Kanban view:
- Added a toggle button to publish/unpublish a job offer.
- In the menu, added the « Create Interview Form » button to create an interview form.
Hr.applicant:
Generale:
- Use of the "Applicant: Acknowledgement" template by default when an application is moved to the "First Interview" stage.
Form view:
- Possibility to consult an interview after this one and not before
- The "CREATE EMPLOYEE" button no longer directly creates an employee. The employee will be created if the "SAVE" button is pressed.
Hr.employee:
Generale:
- Added of two new certifications.
And some other minor style and name changes.
closesodoo/odoo#55928
Related: odoo/enterprise#12420
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1. Generic timesheets improvements
- Portal /my/timesheets
- Add a group bys task, date, employee
- Add search in project, name, employee, task
* The task column should not be visible if none of the timesheets have the Task field set
- If a group by task, date, employee or project is applied, the corresponding column should not be visible
2. Timesheets from sub-tasks on parent tasks
- Portal /my/tasks
- Display the 'Total Hours' spent on a task at the end of the list of timesheets
- Below the list of timesheets for the task, display another table detailing the respective timesheets (and total hours) of each sub-task linked to this task (= 1 table/list per sub-task)
* Title should be: 'Timesheets for sub-task: xyz'
* only visible if there are sub-tasks linked to this task
* only visible if total hours > 0
3. Timesheets on Invoices
- Portal /my/invoices
- Add Project + task fields
* Task field only visible if set on one of the timesheet entries
* Project field only visible if there are at least 2 different projects in these timesheet entries
4. Correct visibility for the portal users
- Portal users is allowed to see timesheets if the users are added in allowed portal users list in the project
- When a portal user is added as the message follower of the project, the user is added to allowed portal users as well
- When a portal user is removed from allowed portal users, the user is also removed from message followers
closesodoo/odoo#47248
Taskid: 2201908
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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>
A record of the basic model may need to be displayed in different
views (e.g. a o2m record is displayed in the, e.g., Kanban view
inside the main form view, and if clicked, it is also displayed
in the form view opened in a dialog). However, the fields present
in those views may differ.
The previous implementation of fieldsInfo in the record didn't
handle that, as it was a dict whose keys were field names. With
this commit, the fieldsInfo is dict whose keys are view types, and
the values are dicts whose keys are field names (the fields of
the corresponding views, with they attrs in the view).
This allows to create multiple o2m records in a row in a form view.
* Data manager load_view returns a viewInfo object
* ViewInfo contains: the arch, fields and fieldsInfo objects, and some extra informations
* The fields come from the server and are frozen, without any view attributes (depend of the model).
* The fieldsInfo contains every view attributes and informations.
Before this commit, the AbstractField specialization to use to
instantiate a field was determined in the renderers. Now this is
regrouped in BasicView.
Note: renderers are still left free to not use the determined
Class (like Kanban and not editable List which instantiate widgets
only if the "widget" attribute is present).
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
Qiuyu (QHO)