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>
1. base: Load translation when language is activated
Purpose
------
Settings > Translations > Languages > I find the language I want
and I click on stat button to activate it.
Now I set it up on my user, it still doesn't work > the langage has not been loaded !!!
Specification
-------
When activating a language load the translation (and open the load translation wizard)
2. base: Add shortcut button to load language
Pupose
-------
On the res.partner and res.user form view if you want to change
the language, it's not easy to know where I can activate more
langages.
Specification
-----------
Add a small icon next to the language field to activate more
languages (similar interface than to send an SMS).
3. base: Clean res.lang tree view
1. Set limit to 200 to display all current 82 languages
in one page (current limit is 80/82).
2. Move some fields to debug mode.
3. Add a button to directly load a language.
4. base: Remove Load a Translation menu
Activating a language automatically load the translation,
hence the menu is no longer necessary.
5. base: Don't show language if only one active
If only one language is active, don't show in the contact
form view (`res.partner`) the language field. Changing the language is
not possible since there is only one language.
Hence the field is useless and therefore hidden.
TaskID: 2026150
closesodoo/odoo#34661
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If only one language is active, don't show in the contact
form view (`res.partner`) the language field. Changing the language is
not possible since there is only one language.
Hence the field is useless and therefore hidden.
1. Set limit to 200 to display all current 82 languages
in one page (current limit is 80/82).
2. Move some fields to debug mode.
3. Add a button to directly load a language.
Pupose
======
On the res.partner and res.user form view if you want to change
the language, it's not easy to know where I can activate more
langages.
Specification
=============
Add a small icon next to the language field to activate more
languages (similar interface than to send an SMS).
Purpose
=======
Settings > Translations > Languages > I find the language I want
and I click on stat button to activate it.
Now I set it up on my user, it still doesn't work > the langage has not been loaded !!!
Specification
=============
When activating a language load the translation (and open the load translation wizard)
To avoid having to wait the cron that distribute badges to elligible users,
we run the cron manually at the survey passed
if the survey is a certification and if the certification delivers a badge.
Task ID : 1935136
PR #31486
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
PURPOSE
Refactor SMS to better integrate it in interface and Discuss. Allow users to
send texts in different business objects: crm.lead, event.event, etc. Introduce
SMS templates to ease mass SMS sending and scheduling.
DETAILS
This merge is mainly a big refactoring of SMS module. Future commits will come
with improvements in various addons to better include SMS, notably: crm,
events, scheduled actions, mass sms, marketing automation, stock, ...
This merge has been done in several main steps
* preparing mail to send hold other notification methods than Inbox and
email;
* refactor / improve posting with SMS notifications;
* improve SMS composer;
* add SMS templates and integrate them in composer;
* integrate into Discuss UX with wizards to resend and cancel failed
notifications;
* add tests;
See sub commits for more details.
Related to task 1922163
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
closesodoo/odoo#33510
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Lucas Lefèvre