PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Guidelines: re-organize model files and split them according to main
models. Also reorganize views.
Done in this commit
* split big python file by main models;
* split views according to python files;
* move statistics report to /report;
* merge some exploded view files (assets, snippets, application menus);
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
The layer created to handle the valuation and costing change share the
same code but they should not share the same description.
closesodoo/odoo#34952
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
adds field_name data on category and filter lists in the
search panel template so it can be used to identify their field.
this improvement is used in the drag & drop features introduced
in the documents search panel (https://github.com/odoo/enterprise/pull/4805).
Task: #1998014closesodoo/odoo#34813
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Create a new report in order to see quantity in the past
and in the future. Also display the planned in and out moves
at their schedule date. The view available for this report is
a graph view even if it could be display with other views.
Technically it's an SQL views based on stock.quant and stock.move
Currently the interval for the report is -3 months, +3 months because
the forecast quantity is based on quants - moves during this interval
in order to keep a linear performance that's not growing with the data.
task: 2000948
closesodoo/odoo#34898
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The move form view from 'stock move' menu item and the form_view_ref
from the picking's operations was different. However we would like the
same kind of information from each side.
This commit remove the view from picking and complete the view from
menu item.
- Add a related on the lunch.supplier to the company id of the linked res.partner
- Add related on the product: to the company id of the linked lunch.supplier
- add multi company Record rules
closesodoo/odoo#34859
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to reset the optional product
when user change the quotation template
task-2005838
closesodoo/odoo#34048
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Accept payment on Paypal without having a merchant account
The merchant only need an email address to accept payment from Paypal
Paypal will send email to the merchant to create an account with the details
Odoo will send mail to the merchant to fill all the credentials after creating an account
Note: why used rm? - If IPN is disabled in the profile (case for the new user), the default action to call the return_url is a GET. This means that if your return_url is a script, you must set rm = 2 in order to have the IPN variable POSTed to that URL
task- 34668
The activation of languages was changed at bd3a553ad9
This commit makes a few changes/fixes
- When executing the toggle_active method do not open the wizard but load
directly the language
- Rename the name of the button in tree view, Download was confusing as implies
the resources are downloaded while it is only loaded
- Remove duplicated help
- Add action button to load the language from the form view (as it the only way
from the form view was using the "Unarchive" action)
- Add label directly next to the field (was making a line return)
- Set the placeholder on the field (no effect on the label)
- Remove groups as the view is already restricted to system users
Follow-up of task id 2026150
closesodoo/odoo#34940
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It is currently impossible to create a company.
The reason being that the newly created company is
not yet in context `allowed_company_ids`.
Therefore, every consequent access to a record protected with
a multi company `ir.rule` fails for that company.
Here, the module automatically creates a project in that company
and later read that project to check a constraint.
The read raises an AccessError, hence the company is not created.
On the other hand, a user without project creation access rights
but erp manager could want to create a company. It should work
in that case too, as the project creation is transparent to the
user and the project is archived.
closesodoo/odoo#34920
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Different templates were defined for graph, pivot and cohort views
for the no content helper. Those templates were similar (only the
message sometimes slighlty changed). This rev. creates one generic
template used by those three views.
closesodoo/odoo#34916
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
So far there are no IoT drivers for serial equipment.
This adds a base IoT serial driver as well as a base IoT serial scale driver and drivers for the two previously supported scales. For the moment the scale drivers support both the old routes and the new event and action routes.
Task: 1892412
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#33800
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit the continuous reading of the scale
was started directly in `show`.
In order for us to be able to use the scale with IoT drivers
this piece of code needs to be overriden, so it was moved to a separate function.
Task: 1892412
This commit adds a base serial and a base serial scale iot drivers,
as well as drivers extending them for the two previously supported scales
(ADAM EQUIPMENT AZEXTRA and TOLEDO 8217).
Since just adding the new drivers creates a race condition
between the old drivers and the new, the old drivers need to be removed.
The IoT scale drivers need to be backward compatible and compatible with the community version,
so client using an IoT box with those versions can still connect a scale to the PoS.
Task: 1892412
The public user doesn't have an email address.
To start a livechat conversation, the email of the user that start the
conversation is used. As the conversation was started in sudo,
the system user's email address was used.
But, since changes with sudo() and with_users(),
the public user is not able to start a livechat conversation
as the system email is not used anymore in this case as sudo is not
changing the user but only skip the user's access right.
To start a livechat conversation, and to post a message, at least
email_from must be filled in.
Anonymous name is used to fill in email_from to bypass the checks
and to build the author given back the thread window.
If anonymous name is empty, we fallback on the company's catchall email
from the mail.channel create user.
Pre-required for task ID: 2028059
Fix Task : 2037048
PR #34918
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We add two warnings to make the --test-file argument more user friendly:
- one when the test file does not exist
example:
./odoo-bin -d master --test-file ./addonss/stock/tests/test_quant.py
before:
INFO master odoo.service.server: loading test file ./addonss/stock/tests/test_quant.py
after:
WARNING master odoo.service.server: test file ./addonss/stock/tests/test_quant.py cannot be found
- one when the test file is not a python file
In both cases, nothing was being tested but the server did not say why.
closesodoo/odoo#34808
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
- Reorganize configure your order screen
- Alert users through chat: Alerts can now be configured to
send a chat message to the employees.
- Replace toppings by extras
closesodoo/odoo#34470
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- after this commit, a user can search for the coupon by name from
the search panel.
- some typo fixed
task-1972686
closesodoo/odoo#34372
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Perf for the creation
=====================
The biggest impact of this change is when each template has only very few
variants to generate and there are a lot of such templates.
And when few templates generate a lot of variants this is potentially just a bit
better than before, and not definitely not worse.
The opposite change was done in commit f8dad1bb4b
due to an issue with unlink but since the unlink is changed to use dichotomy now
we have the best of both solutions.
For example when creating 10000 products, few with a lot of variants (max 1000)
and many with few variants (or only one), the time it takes goes down from at
least 10min (the attempt was canceled before the end) to only 25s.
Perf for the unlink
===================
For the following test case:
- create a template
- give it 3 attributes, 10 values each
- -> that generates 1000 variants
- add the first variant to an order to test it
- not happy with the config, remove one of the attributes from the template
- -> that removes the 1000 variants
This is slow because of the `savepoint` used to archive if `unlink` fails.
With dichotomy it takes 14s.
With a loop (one by one) it takes 5min.
Part of task-1918881
closesodoo/odoo#34650
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose
=======
Some formviews are useless since there are so few relevant fields https://nimb.ws/1EdMV7
For instance, to create a new lost reason the user is forced to:
1. Hit create
2. Type in the name of the record
3. Hit save
4. Go back to the treeview
While he could simply type them away in an editable treeview.
The goal of this task is to allow for creation/edition of records in such models
directly from the treeview.
Specification
=============
Modify tree views from a given list of models for which the
treeview has to be made editable bottom.
If not specified otherwise, the content treeview should stay the same.
If a field is readonly/required/etc. in the formview, it should be in the
editable treeview as well.
Relabeling has to be done of the field itself, not in the view.
TaskID: 2026126
closesodoo/odoo#34577
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Parentheses in the label of units of measure sometimes make
reading needlessly uncomfortable.
Specification
=============
Remove parentheses in the name of every standard uom.uom and hardcoded
occurence on views/field names.
TaskID: 2030444
closesodoo/odoo#34492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Explicitely return the extension of the listview to allow to modify it
in other modules
closesodoo/odoo#34672
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
-In Kanban view of products, it should allow to create a
product or import it
task-2032878
closesodoo/odoo#34660
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This inner join permit to have filters on orders to be executed earlier in the query plan
In a multi-company environment with millions of pos lines, the difference is about 10% faster
As you cannot have a line without order, this doesn't introduce reggression.
closesodoo/odoo#34849
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
On runbot, edit SO131 and change the company
=> traceback
An onchange is triggered (=> self.id is a NewId).
But while recomputing the quantity delivered, a
read_group is performed which gives real ids (int).
The ids are then used to retrieve some so_lines in a
dict where each key is an id (but actually NewId
in onchange) of self.
=> the keys are NewIds but try to get the value with an (int) id
=> KeyError
closesodoo/odoo#34818
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Website crm phone validation does not hold code that cannot be located in
website_crm as dependencies are now the same. Let us merge those two
modules !
Linked to task 2033777
closesodoo/odoo#34744
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As multiple users will be able to login in the main session, we
shouldn't use the user_id of a session to find the correct session, but
we are only depending on the pos_config
closesodoo/odoo#34623
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before, when a pos order was created, some of its values were were
completed through the default mechanism that was looking for a session
opened by the current user, which could lead to wrong values when with
recovery session. Since in near future we'll allow one user to open
multiple sessions, this behavior won't work anymore, as you could get
the config od another session than the one you are working on.
We also removed the '_default_session' on field session_id, as the
method 'create_from_ui' which creates the orders from the frontend
allways set the session_id when it creates a new order.
TASK-ID: 2032769
In Inventory, we have an option to print the report of Barcode in ZPL but we do
not have option to print the same in PDF.
After this commit, there will be a PDF version of the report of Barcodes
available just similar to the report in ZPL.
task-1970506
closesodoo/odoo#32935
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
There are currently multiple ways to determine if an employee is presence
or absent:
- login state (user status on chat)
- checkin/checkout from the Attendance app
- leave
- hr_presence (email, ip)
Those states are displayed in several different places and can be inconsitent.
e.g. Logged in -> green in the chat
Not checked in -> red on the employee kanban view.
The multiple ways to determine employee presence described above
should be aggregated together to have a better consistency.
Specification
=============
There are 3 presence states (previously defined in module `hr_presence`),
namely `present`, `absent`, `to_define`. They are now defined as soon as
`hr` module is installed.
The state computation can have several behaviors according to which apps
are installed:
1. `hr` is installed
Check employee presence based on login by default (only for employees with
a user).
Kanban state (private and public): should be green when logged in, red when logged out and
orange when the user is away.
Private employee form: Display a stat button "Connected" on the form view
when the user is logged in or "Last Activity xx/xx/xxx" otherwise.
2. `hr_attendance` is installed:
when the user is logged out, the state
is determined from the checked in/out state. But when the user is logged in,
consider the user as present (even if he checked out).
Kanban state: green for checked in, red for checked out
Private form view: attendance stat button.
3. `hr_holidays` is installed:
Has the highest priority if the employee is on leave.
Kanban state: red if employee is on leave.
Private form view: stat button "Absent Until xx/xx/xxxx" if employee
is on leave.
4. `hr_presence` is installed:
Two additionnal presence checking option: emails sent and IP address connected.
Once a user sent an email or the IP address was connected, he is considered
present for the entire day.
There should be at most one stat button on the employee form view, with the
relevent information.
Task id: 2024482
closesodoo/odoo#34933
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1/ Change stat button landing page
----------------------------------
Currently when clicking on the leave stat button
of an employee, the landing page is the leave dashbord of the current
user.
It's more usefull for HR people to land on the reporting
view of the employee.
2/ Remove stat button from public employee
------------------------------------------
It's useless for regular employees to know how
many remaining leave others have.
Hence the stat button is removed from the public
employee form view.
As Marc Demo, at the begining of the month, through
the client action, you can checkin but not checkout.
There is one limitation in the way the attendance state is computed:
It uses the attendance with the most recent checkin date.
Therefore, if an attendance is created in the future, it's the later
attendance which is taken into account, not the current attendance.
Steps to reproduce the problem:
1. Create an attendance in the future with both start and end
date set.
2. Through the client action: checkin
=> the client action stays on the checkin screen because you are
considered as checkout. Hence you cannot checkout.
It's difficult to change the way the state is computed, especially
having the right triggers.
Adding a constraint to avoid attendance in the future is probably a
bad idea. It could unintentionaly fail if the user's time is off by
a few minutes on his computer.
On the other hand, this situation should rarely happen (only when manually
creating an attendance, which has little functional sense).
Solution: Fix demo data to avoid attendances in the future.
Tests needed to be adapted because they used demo data. They no longer
use demo data.
This PR 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.
Note : To avoid having to create a bridge module 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
closesodoo/odoo#31486
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Avoid a complete reload of the web client when adding a optional
product, which loses searches, breadcrumb, etc.
This is achieved by adding a non-stored 'is_present' computed field
which is computed depending on the presence of a SO line linked to the
option line - that way its is dynamically adapted when the option is
added to the SO. Since we wanted a clear feedback when the option was
added to the quote, green colouring and the disappearance of the 'add
to quote' button have been added.
Note that this field *cannot* be stored - since the line_id field on the
option bypasses the ORM (`set null` for the on_delete attribute), it
would not recompute properly upon deletion of the linked SO line.
Task#1950410
closesodoo/odoo#34929
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Thibault Delavallée