Purpose
=======
Currently the payroll doens't manage the multi company
Specification
=============
1/ Add ir.rules on hr.contract and hr.payslip to prevent users
to access a record in another company.
2/ Add ir.rules on hr.payroll.structure to prevent users to access
a record for another country.
3/ Remove company_id fields on models that doesn't require it, as
hr.salary.rule.category.
4/ Make the accounting fields on the salary rules company dependent.
5/ Specify the country on the salary structures on the
l10n_**_hr_payroll modules.
6/ Add demo data and modify the salary package tour.
7/ Make the car_atn and company_car_total_depreciated_costs fields
compute_sudo=True, as one car can be assigned on several contract,
for different companies
Closes#26866Closes#25231Closes#24683Closes#23814
Before this commit
- Install a **l10n_xx_hr_payroll** which includes information of the rules (it always install in the main company: **Company A** in this use case).
- Configure the accounting for the rules
- Create **Company B**
- Use the same salary rules for both companies, as **l10n_xx_hr_payroll** modules are not multicompany.
Behavior:
- **Company A** accounts are shown in **Company B** salary rules.
- If the accounts are changed in **Company B** rules, it also overrides **Company A** accounts, (which causes major confusions, and great mistakes if a payslip is run).
- A salary rule with **Company A** set on `company_id` can still be **seen** through Company B. which causes that it can be mistakenly _ran by a user in Company B_, with the _accounting of Company A_.
After this commit:
Salary rules accounting can be used with multi-company
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the customize theme dialog was not opening anymore.
This was due because, somehow, the editor's merge changed the theme
dialog code for no reason.
closesodoo/odoo#30365
We would like to automatize lunch as currently all orders are manually ordered and validated,
and a cash move has to be manually created each time you want to credit the wallet of some user.
1/ In this commit we add a new widget that comes with the kanban view
and will allow to take orders in a friendly manner.
2/ We also add a lunch.supplier model this also allows you to configure an
automatic ordering via email.
3/ Introduces new lunch.location model to replace res.partner on suppliers
4/ New mail template for automatic ordering
5/ Add the concept of new products (mark a product as new until some date)
6/ The toppings are now defined by product category
7/ Lunch.order removed, lunch.order.line renamed into lunch.order
8/ New SQL report to get the wallet content (aggregate of lunch.cashmove and lunch.order)
9/ New setting to allow negative wallet (aka overdraft)
10/ Application now remembers what notes and toppings you last ordered with your product
11/ You can change your location using the widget on the kanban view
12/ Edition of the order can be done until the order is arrived
TaskID: 1856876
TaskID: 1916105
closesodoo/odoo#30028
This commit improves general usability.
Specification
=============
Screens usability:
1/ Benefits
1.1/ Calendar
- Add a sidebar filter to filter employees. The filters are saved per user.
If no filter exists for the user the 'Everybody' filter should be true by default.
- Generate benefits when clicking on the menu -> remove the wizard (popup): generate benefits for all running contracts
- Once generated, don't show again the generate benefits button: only show the Validate button
- Generate Payslips button: remove the wizard. It generates payslip of validated benefits
and jumps to the payslip batch form view.
1.2/ Form:
- rename: Start into "From"
- rename: End into "To"
- rename: Hours into "Period" (add 'hours' as unit on the right of the field)
2/ Payslip
2.1/ Form:
- Remove Payslip stat button.
- a computed payslip should be editable
2.2/ List:
- show: Reference | Employee | Batch Name | From | To | Gross Salary | Net Salary | Status
- In action buttons add a "Confirm" to confirm multiple payslips
- add a quick search on contract
- filters: rename 'draft' into "To Compute"
- filter: add "To Confirm"
Menus:
1/ Salary Computation
- Benefits (object: hr.benefit ; view: calendar, list, form, pivot. Group: hr officer ; filters: group by employee in the view)
- Payslips (objetc: hr.payslip ; Views: list, form, pivot. Group: hr officer ; filters: last batch ; Sort: employee name alphabetically)
2/ Employee Payslips
- Batches (objetc: hr.payslip.run ; Views: list, form. Group: hr officer ; Sort: creation date (last one first)
- All Payslips (objetc: hr.payslip ; Views: list, form, pivot. Group: hr officer ; filters: no filters; Sort: employee name alphabetically)
3/ Configuration
- Settings
---Salary---
- Rules
- Structure
- Contributions Registers
---Benefits---
- Benefits Type
---Repository---
- Employees (list)
- Contracts
When a benefit linked to a leave is cancelled, it should refuse the leave.
When a payslip batch is deleted, also delete associated payslips.
+ Refactoring of benefit js to use "Odoo style" event binding.
TaskID: 1916136
closesodoo/odoo#30110
This commit improves general usability.
Specification
=============
Screens usability:
1/ Benefits
1.1/ Calendar
- Add a sidebar filter to filter employees. The filters are saved per user.
If no filter exists for the user the 'Everybody' filter should be true by default.
- Generate benefits when clicking on the menu -> remove the wizard (popup): generate benefits for all running contracts
- Once generated, don't show again the generate benefits button: only show the Validate button
- Generate Payslips button: remove the wizard. It generates payslip of validated benefits
and jumps to the payslip batch form view.
1.2/ Form:
- rename: Start into "From"
- rename: End into "To"
- rename: Hours into "Period" (add 'hours' as unit on the right of the field)
2/ Payslip
2.1/ Form:
- Remove Payslip stat button.
- a computed payslip should be editable
2.2/ List:
- show: Reference | Employee | Batch Name | From | To | Gross Salary | Net Salary | Status
- In action buttons add a "Confirm" to confirm multiple payslips
- add a quick search on contract
- filters: rename 'draft' into "To Compute"
- filter: add "To Confirm"
Menus:
1/ Salary Computation
- Benefits (object: hr.benefit ; view: calendar, list, form, pivot. Group: hr officer ; filters: group by employee in the view)
- Payslips (objetc: hr.payslip ; Views: list, form, pivot. Group: hr officer ; filters: last batch ; Sort: employee name alphabetically)
2/ Employee Payslips
- Batches (objetc: hr.payslip.run ; Views: list, form. Group: hr officer ; Sort: creation date (last one first)
- All Payslips (objetc: hr.payslip ; Views: list, form, pivot. Group: hr officer ; filters: no filters; Sort: employee name alphabetically)
3/ Configuration
- Settings
---Salary---
- Rules
- Structure
- Contributions Registers
---Benefits---
- Benefits Type
---Repository---
- Employees (list)
- Contracts
When a benefit linked to a leave is cancelled, it should refuse the leave.
When a payslip batch is deleted, also delete associated payslips.
+ Refactoring of benefit js to use "Odoo style" event binding.
Adding `res_model` and `res_fields` attributes on a field of
a calendar view adds a filter in the sidebar.
It saves the result as the defined model and should save it
in the defined field.
However `partner_id` has been hardcoded in the rpc call that creates
the record. This breaks genericity, it cannot be used with another
field than `partner_id`.
This commit makes this generic by correctly setting the field name
in the rpc call.
This allows a model to have several fields using the same relation on purpose,
for instance to show the related items filtered by domains.
Also adapt the code to handle multiple many2many inverses.
closesodoo/odoo#30338
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
This commit introduces the "upload file" activity type
category. For an activity of that time, uploading a file
will mark the activity as done (and maybe create the forced
next activities).
This activity type is seen as a shortcut to upload a file
with a reminder.
Task-1915004
closesodoo/odoo#29861
The purpose of this commit is to factorize the common behavior of
marking an activity as done, which means delete it and create its
forced next activities.
We need a few entry points (for wizard button, for rpc calls from
webclient), so instead of rewritting every implementation, we make
them use the same new private method. Otherwise, adding a new way
to mark an acitivity as done (by uploading a file, for instance),
we gonna need to write quite similar method that the existing ones.
Unfortunately, in the private implementation of `_action_done`,
checking if some activities need to have their force next ones
created cost one more query.
As this refectoring make the activity lifecycle robust, we can
accept this (the old version might be consider as false as we can
mark an activity as done without creating its forced next
activities).
Task-1915004
This merge provides many little changes to improve the usability
and the onboarding of users in project and timesheet
applications.
This mostly contains labels renaming, restruration of views, ...
but some new mecanism appears like the "ghost kanban examples",
and improvements of the kanban examples modal.
Task-1893021
closesodoo/odoo#28461
During cleaning from ee2631cd51,
as the kwargs were removed from arguments for some routes,
debug mode was not accessible anymore as ?debug=x is, de facto,
a post argument.
This commit restores debug mode by restoring kwargs in those routes.
Fix commit from task ID 1911586 and PR #28986
Integrated in task ID 1911291 and PR #29054
Create data for all tests in order to speed data test creation. We don't want the test to be demo data dependent
What we are testing in this test case.
-> Check that procurement is creating requisition with correct details or not.
-> Check that purchase order created is consistent when we create it with supplier info.
-> Two blanket orders on different 'make to order' products must generate two different purchase orders.
Task ID : 1851286
closesodoo/odoo#30187
The purpose of this commit is to make requisition usable with only services. Stock part is extracted in a new module `purchase_requisition_stock` which allows to create requisition based on product availbility or demand, also
we have moved all security access related stock in this bridge module.
Task ID : 1851286
_Task #1878502_
- The refactoring allows for the update of the _Summernote_ library.
- A new structure was created by transforming all the plugins in the library using the odoo inheritance system. Plugins are easier to implement with the `AbstractPlugin` to add Odoo behaviors.
- The cleanup allowed us to remove some of the code that was in `web_editor` but only used in `website` or in `mass_mailing`. Some parts are still in `web_editor` but will be moved at a later time.
- The refactoring also had to be done in order to create a set of unit tests. Each behavior can be tested, including the behaviors performed as a consequence of keyboard interactions (for instance: Enter, Tab...).
- From now on, the methods of the library (in this case _Summernote_) can no longer be called by other modules or files. Only the `wysiwyg` widgets can access it, to simplify the updating process. The `wysiwyg` object serves as an interface. A lot of tests are done, ensuring the consistency of outside behavior.
- Depending on the options the snippets will be loaded or not, the editor will be in an iframe or not... all of this is transparent from the outside.
- Regarding iframes, all controllers related to editing have been removed: the new API no longer needs them. This speeds up loading, eases testing and removes complexity for the same features.
**PUBLIC FEATURES**
There are several public methods on the `Wysiwyg` class:
- `Wysiwyg.prepare (WidgetParent)` which returns a deferred resolved when the library (xml, lazy, assets...) is loaded.
- `Wysiwyg.getRange (DOM)` returns the range (selection in the dom)
- `Wysiwyg.setRange (startNode, startOffset, endNode, endOffset)` which creates a range (selection in the dom)
- `Wysiwyg.setRangeFromNode (DOM, options)` that creates a range from an element (option available to select all, start or end)
A jQuery selector was added: `:o_editable`, which indicates whether the current element is editable. That is, if it is contained in a tag with the attribute `contentEditable = "true"` or in a tag with the class `o_editable`.
Several methods are also present:
- `focusIn`: makes a focus and places the cursor at the beginning of the element
- `focusInEnd`: makes a focus and places the cursor at the end of the element
- `selectContent`: makes a focus and selects the content
**HTML FIELD**
The HTML field can receive different options:
- `style-inline:` {boolean} transforms a class into an inline style when saving and vice versa when reading.
- `no-attachment`: {boolean} prevents the use of attachments (in media dialog)
- `cssEdit`: {xml_id} to use a template containing the css to loaded in an iframe when editing
- `cssReadonly`: {xml_id} to use a template containing the css to load into an iframe when viewing in readonly
- `snippets`: {xml_id} snippets template (can be used with or without `cssEdit`)
- `wrapper`: {template} qweb static template (containing a tag: `id = "wrapper"`) that will include the content during editing (removed on save)
**MASS MAILING**
A widget was created for `mass mailing`. There are now two fields: `body_html` and `body_arch`.
`body_arch` contains the code with the class without conversion into inline style, useful when editing and one with the inline style that is visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do more changes when converting to inline style so that a maximum of mail clients have an impeccable rendering.
**REMAINING KNOW ISSUES**
These will be fixed in a subsequent commit.
- A few committed changes made during the development of this refactoring were lost in the process and should be reapplied.
- Some minor (mostly range) issues remain with Firefox.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#29775
Purpose of this task is to allow marketing people to differentiate the
mailing name (internal reference) from the subject used in the mailing
emails.
Mailing name is actually the UTM source name as mass mailing inherits
from it. Being able to edit it independently from the subject allows
to better categorize / filter mailings without sending technical terms
to customers. Marketing users could also change and tweak mailing subject
without disorganizing the pipe and changing the URM source name.
Demo data are updated accordingly to have both subject and mailing
names.
This commit is linked to task ID 1917602 and PR #29514.
The refactoring also had to be done in order to create a set of unit
tests.
Each behavior can be tested, including the behaviors performed as a
consequence of keyboard interactions (for instance: Enter, Tab...).
This commit also contains some changes to test_utils that were
necessary given the new structure of the wysiwyg editor.
Co-authored-by: Gorash <chm@odoo.com>
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
The refactoring of the wysiwyg editor and 'html' field allows us to
move some of the code that was in web_editor but only used in website or
in mass_mailing. Some parts are still in web_editor but will be
moved at a later time.
- Improve the website tour (typo, tip positions, etc) and added new
steps to publish a new page
- Make close button of 'Mobile Preview' more visible
- Fix the overflow for long menu names in menu editor dialog
- Change the menu string from 'Affix Top Menu' to 'Fixed Top Menu'
- Change theme customization dialog's title to 'Customize Theme'
from 'Customize this theme'
- Improve strings for Google Analytics
task-1895287
closesodoo/odoo#28199
The background example is a set of random fake column and card,
directly inspired from the kanban example modal.
We want to toggle this background depending on the kanban state;
the background will be displayed when there is no column yet,
and the quick create column is shown.
To do so, we need to update the state of the kanban when deleting
a column to (re)display the background in case of removal of the
last column. Now, on column deletion, the entire kanban is updated
and so entirely rerender (with aab's benediction).
Task-1893021
Prevent user to create project on the fly when
editing task. This will avoid user to create bad
project (typo, ...) and will force then to be more
organized: create a project first, then populate
it with tasks.
Task-1893021
This commit makes the create button of a kanban view
jumping when the user click on some zone on the kanban
background.
The purpose here is to educate the user, so he can learn
how to create its first kanban card.
Task-1893021
Purpose
=======
In order to be able to manage payroll, we need to know if a resource calendar
is a full time or a part time. For instance, in belgium, 23h a week is a full
time for a teacher but in cp 200 it is 38h. In belgium every employee can take a
parental leave in part time but he cannot take it in part time if they are not full time.
Having a field indicating if the contract is full time or not is useful for computing
salary rules.
Specification
=============
On the calendar model
- Display a computed field with the number of hours in the calendar
- Display a field with the required number of hours to be full time
- Display a computed checkbox, ticked if full time or not
On the contract model
- Add a related on these fields, to ease the access on the salary rules computation.
closesodoo/odoo#30034
Purpose of this commit is to remove test entries from statistics and reports
in survey. Indeed they are not real results and should not be taken into
account. We also display a warning on portal page of surveys when user is
in test mode.
This commit is linked to task ID 1865453 and PR #29316.
Task #1907952
Purpose
=======
The number of generated leads/opportunities from the mass mailing on the stat button should count
both active and archived leads/opportunities.
The stat buttons on mass mailing added by sales and crm apps should appear on every selected 'model'
for the recipients (a mass mailing sent to 'leads' can generate sales).
Specs
=======
Opportunity stat button:
- double check that the number is based on both leads or opportunities, active or archived
Stat buttons Leads #, Quotations #, Invoice Amount should appear on the form all the time for showcase purposes
closesodoo/odoo#29568
Purpose of this merge is to refactor, clarify and fix surveys access rights
and rules. Indeed currently surveys access rights and rules are not very
clear. This application is currently used mainly for external and public
surveys.
In this merge we clean access on survey models. Basically only surveys officers
and managers have access to the models. Other people including employees,
portal users and anonymous people users have to use the portal view and
dedicated routes instead of accessing data through the backend.
In this merge we also expand the access options of surveys. Surveys can be
public, limited to authenticated people, limited to employees or on invitation
only. Invite wizard has been redone to simplify it and better support those
options.
For more details about the content please have a look at each subcommits.
This merge is linked to task ID 1911586 and PR #28986.
Otherwise you might change the survey used on the job without knowing it.
Survey on applicant is just there for information / action purpose, not
configure the job itself.
This commit is linked to task ID 1911586 and PR #28986.
Purpose of this commit is to add a new survey category for applicants. That
way surveys created and/or used through recruitment process are correctly
set in their own category allowing to filter them. When creating a new
recruitment only surveys linked to recruitment process are shown. Moreover
default values are propagated when creating new surveys so that they are
correctly configured by default as recruitment and invite-only surveys.
This commit is linked to task ID 1911586 and PR #28986.
Purpose of this commit is to add a category selection field on surveys. It
will allow to filter / select surveys according to their category and their
main use.
This commit is linked to task ID 1911586 and PR #28986.
Recent community commit updated survey ACLs. Notably survey access groups
officer and manager have been updated to really give access to survey models
management. Other people cannot access survey models as they are considered
technical. Controllers give a way to take and complete surveys.
In this commit we update recruitment bridge module with survey to remove
custom rights and rules definition for survey models. As recruitment groups
already imply survey groups access defined in base survey should be sufficient.
Being a recruitment officer or manager automatically makes the user a survey
officer.
This commit is linked to task ID 1911586 and PR #28986.