The accounting date and the related warnings were in some cases not
being set properly. This change aims to improve that by displaying
warnings in the view and updating the date on post instead of raising
user errors.
This will mostly affect sell documents.
Task id #2778958closesodoo/odoo#85744
X-original-commit: 51ddb870d346ff61a6ae36c8c3b545eaca9736cb
Signed-off-by: William André (wan) <wan@odoo.com>
As of now, the discount field is either only shown in
debug mode or if the sale module is installed and a
setting is set in sale.
This field should be shown in the view, and not depend
on a setting from another app.
This is especially true as it could be filled by the ocr
or when uploading from an edi, and it would be inconsistent
if the user couldn't display it.
Task id #2758965closesodoo/odoo#85737
X-original-commit: eb1a77753debdb034ad00ce10d908f4b9ee264ad
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
whith France localization, deleting a journal created by POS
leads to two errors.
first one is just a typing error.
second one is an infinite loop caused by calling super().unlink()
from methods marked with the api.ondelete
opw-2750852
closesodoo/odoo#85719
X-original-commit: 4961dd251211776a9661f27acda3c3e4dfedc50a
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
According to the spec, the PrezzoUnitario should be the unit price
without the taxes. If we use taxes included, this can be problematic.
That is because there is another rule that says that the PrezzoUnitario
* Quantita - Sconto should be within 0.01 precision of the PrezzoTotale.
So, with taxes included and a price unit only rounded to 2 decimals, you
easily go out of that limit.
The solution is to increase the precision on the price_unit (6 decimals
should not cause side effects and precise enough for most cases)
and to do the calculation differently by calculating it again from the
price_subtotal on the invoice line.
Task id: 2764978
closesodoo/odoo#85718
X-original-commit: 82f2794a2aee8492cbd36d8ab4d8a62c9665789d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
When users have same groups, implied_ids can be done in batches,
reducing write operations considerably.
Testing done:
800 users groups_id (all have same groups_id in the end) updated using
old code: took ~10s to complete.
With this improvement, it takes ~1.5s
closesodoo/odoo#85712
X-original-commit: 81994ea628cb492fef4e62c496d4ea1ab55d9a7e
Signed-off-by: Raphael Collet <rco@odoo.com>
If an installed module is only present in the dependency graph through a new,
uninstalled dependency, it was not be selected for upgrade when updating the
`base` module (c.q. `--update all`)
closesodoo/odoo#85704
X-original-commit: 6c80e7cfeafaaa4fb7c0d93cbe94c66068fc3170
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Since 4911a26d2c, `_check_barcode_uniqueness`
flush the default `_order` of `product.product` models (via many2one in the `_order`
of `product.packaging`). It creates a bottleneck (take > 10 minutes ) when we populate
(medium size) the `product.template` during `set_barcode_variant`.
Force the order to be trivial and simplify the domain with a 'in' instead of
multiple OR.
closesodoo/odoo#85687
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
1. Create a PO from Indian vendor [DEMO], confirm it, receive the products.
2. Go to Accounting app, manually create the vendor bill:
- select the Vendor [DEMO]
- in auto-complete field select the one created at 1.
Traceback will raise because the field l10n_in_company_country_code
was removed from account.move in
17610e8ca9
opw-2745052
closesodoo/odoo#85501
X-original-commit: ffbfdde4b5b4cd791e866341a31cdf5e8aeb27e3
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if we have both customer and assigned partner names,
they are displayed in a single line separated by an arrow icon.
However, if we have long customer name, arrow icon and assigned
partner name are not visible on card.
This commit improves the display of names by making a few changes
- breaking the line before the arrow icon
- displaying both customer and assigned partner name with text overflow
- adding a tooltip on customer and partner names
- improving tooltip on the arrow icon
taskID-2763930
closesodoo/odoo#85264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The field prefetching mechanism was poorly customizable. Before this,
we could only tell if a field was prefetched with other fields or not at
all. We have no way to inform the framework, like: "When I need data of
that field, prefetch these other fields, which are likely be used in the
same transaction".
From now on, the `prefetch` attribute is used as a grouping key for
prefetching fields. When a field is fetched, all the fields with the
same value for `prefetch` are taken for prefetching.
For example, consider a small set of fields that are rarely used, except
for one flow A using them. You want to prefetch those fields only in
the flow A, and you want to fetch them in a single query. With the new
feature, simply set `prefetch=A` for some string `A` on those fields,
and they will be grouped for prefetching.
closesodoo/odoo#85220
Signed-off-by: Rémy Voet <ryv@odoo.com>
Issue
-----
When website is installed, the rendering of template uses a side effect
of the ORM cache (cache shared between sudoed env vs non-sudoed env) and
the fields prefetching feature to work correctly.
The `self.visibility` in (`_handle_visibility`, website/ir_ui_view.py)
is done in sudo mode, then it will fetch all prefetchable fields and put
them in the cache (that will be read in non-sudo mode in the render of
the template). Another example of issue related to this:
https://github.com/odoo/odoo/pull/83341.
Because of this, the fields of mixin `website.seo.metadata` were forced
to be prefetchable (the default for translate is to be not prefetchable
since https://github.com/odoo/odoo/pull/82896), which causes a useless
LEFT JOIN on "ir_translation" in most of business flow.
Fix
---
Remove the `prefetch=True` on mixin fields, and add a extra read to fill
the cache in case of website rendering. It also allows to read these
fields at the same time.
Part-of: odoo/odoo#85220
When we read data of one record, the method `recompute` (`_fetch_field`
-> `_read` -> `flush` -> `recompute`) can take more than 40 % of the
time of the `_read`, due to a huge number of recordset creation (from
`records_to_compute` and `records & recs`). Avoid that waste of time by
postponing the test on records.
For example, on a database with modules crm, mrp, purchase, website,
sale_management, reading the prefetchable fields of the current company
took 1.45 ms ± 60.3 µs, and now takes 1.17 ms ± 110 µs (more than 20%
speedup).
closesodoo/odoo#83818
Related: odoo/enterprise#24645
Signed-off-by: Raphael Collet <rco@odoo.com>
Part-of: odoo/odoo#85220
Notifications have now a new look and SCSS has been cleaned up
accordingly. This commit is part of v16 overall restyle (task-2704984).
task#2719037
closesodoo/odoo#82524
Related: odoo/enterprise#23580
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Currently, we lint and auto-format non-legacy files in web. The tool
that we use for this linting and formatting unfortunately does not
propagate any linting errors except for parsing errors. This means that
it's possible to commit files of which we know in advance that they will
break CI. This commit simply relints the files in a standalone manner
after they've been formatted, so that if there is a linting error, the
commit will be aborted.
It is still possible to commit non-conforming code (eg to save work in
progress before switching branches) by committing with the --no-verify
git flag
closesodoo/odoo#85727
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before, it would give a traceback when we would have a product.supplier_info
with the same code and partner used for multiple products. This way, we
avoid this traceback.
opw-2703669
closesodoo/odoo#85725
X-original-commit: d7b35bb60d84eb587d82a3d9da24e39e8a42af9d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
With owl2, the `el` of components if no longer available. One must
use a t-ref instead. However, higher order components don't have
their own html element. This was the case of the View component.
However, it makes sense for this component to be the owner of the
view root element, which was previously owned by the Layout.
This commit refactors the View/Layout architecture s.t. the root
element is now owned by the View, and simplifies/generalizes the
Layout in the process. The Layout is no longer tied to the notion
of views, and can thus be used in client actions as well.
closesodoo/odoo#85639
Related: odoo/enterprise#24903
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Michael (mcm) <mcm@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
Part-of: odoo/odoo#85639
DateTimeString should have an attribute format="102" (date is of the form: AAAAMMJJ)
as specified in the factur-x documentation.
opw-2767359
closesodoo/odoo#85604
X-original-commit: c367ae0df23ce6a826cdb487b92d25dff3e78963
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when we need to get all SOL linked to the project.
That is the SOL linked to the project and also the SOL linked to all
tasks of this project.
Technically, a fetch is made to get the SOL of the project, a fetch to
get all tasks of the project and then a fetch to get the SOL linked to
all tasks fetched, finally the union is made to avoid having duplicate
sale order items in the recordset
(`self.sale_line_id | self.tasks.sale_line_id`).
This way could be a performance issue if the project contained many
active tasks and so the project update could take more and more time to
compute the sold items shown in the right side panel of project update
view.
This commit does a query builder to fetch the SOLs linked to the project
and its active tasks to avoid doing the prefetchs.
part of task-2710808
closesodoo/odoo#85660
X-original-commit: 0734f4e
Related: odoo/enterprise#24918
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the translation is not done in lazy, so for each
stat button shown in the right side panel of the project update, a query
is done to find the correct translation based on the language of the
user. It means, the translation is costly and need to be done in lazy to
reduce the time for the translation of those stat buttons.
This commit uses the `_lt` to translate in lazy mode those stat
buttons. By doing that, the execution time is reduced from 750 ms to 250 ms.
X-original-commit: 95fe018
Part-of: odoo/odoo#85660
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
To generate an e-faktur
1. Settings > Users & Companies/Compagnies:
- Create a new company ‘ID Indonesia’:
- Set the state (e.g Yogyakarta (ID))
- Set the country ‘Indonesia’
Accounting:
2. > Customers > e-Faktur
- Set a range of numbers (which are supposed to be assigned by the
Indonesian government);
3. > Configuration > Settings
- Fiscal Localization: select the Indonesian package
4. > Customers > Customers
- Create a new res.partner:
- Set the country ‘Indonesia’
- Check ‘ID PKP’ field
- Under ‘Accounting tab’: set both accounting entries (Receivable +
Payable)
5. > Customers > Invoices
- Create a random invoice with the res.partner set in point 5. as the
Customer
- Confirm the invoice
- Action > Download e-Faktur
---
When validating the e-faktur users will see the error
Import Faktur Error ETAX-30005 : Error Objek Mapping
This occur because E-Faktur standard update from 3.0 to 3.1
A column 'KODE_DOKUMEN_PENDUKUNG' is now mandatory
opw-2753810
closesodoo/odoo#85696
X-original-commit: 3f0db73ef7c51c7365afbc7604ea66fa6765e6e7
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Currently, when someone adds a quiz on the slide content from front-end
and clicks on the 'Set Done' button, `werkzeug.exceptions.Forbidden`
error is raised which shows the full stack trace to the end user.
This commit improves the behavior by raising UserError instead and
thus displaying nice error instead of the full stack trace.
taskID-2380233
closesodoo/odoo#85694
X-original-commit: 5dfd5dd50fa8cd3f023ba7fa0c2fc4b52f9c5650
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Previously when going to a contract from the contract history, studio
was disabled, because it could not find a action xml id attached.
TaskId-
closesodoo/odoo#85690
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When using the odoo app,
`request.httprequest.user_agent.browser` is `False`,
instead of a string expected.
Therefore, `capitalize` cannot be called
```
2022-03-02 09:44:01,267 1321846 ERROR dle-test1 odoo.addons.saas_trial.models.res_users: 2fa by email failed
Traceback (most recent call last):
File "/home/odoo/src/custom/trial/saas_trial/models/res_users.py", line 267, in _send_totp_mail_code
return super()._send_totp_mail_code()
File "/home/odoo/src/odoo/saas-15.1/addons/auth_totp_mail_enforce/models/res_users.py", line 95, in _send_totp_mail_code
'browser': request.httprequest.user_agent.browser.capitalize(),
AttributeError: 'NoneType' object has no attribute 'capitalize'
```
closesodoo/odoo#85684
X-original-commit: 5a87db453fcfd750934d1a1d62c00d93ad01c0e1
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
To reproduce the issue:
1. Storable product with MTO and manufacture route
2. On your warehouse set 3 steps manufacture
3. Create and Confirm a SO for this product
Error: The smart button linking the Manufacturing order does not appear
on the MO.
Problem was introduced by [1] and fixed by [2,3]. Moreover, [1] wasn't
deployed on versions >14.0 so there was no need for [2] on these
versions ([3] has been merged on all versions). However, [1] have
recently been deployed on next versions ([4]) so we need to FW [2] too
without disturbing the improvements from [3].
[1] 7ab0ac3e56949e5015bb2dcfd2af34b56dee92c8
[2] 96b56ea350c283d824468c591d42e4aeeada0d69
[3] 475e6b3cb027b3127b8e46fd8c9f90abc35162d7
[4] 7d7976a61d0af41ebb4df2e24ba222f6570f689c
OPW-2778883
closesodoo/odoo#85676
X-original-commit: 8ce61133af600ffec4c43033e64c2460366856ce
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
ISSUE 01
When adding a product to a sale delivery, another picking is generated
to return the additional product
To reproduce the issue:
1. Create two consumable products P01 and P02
2. Create and confirm a SO with 1 x P01
3. Add 1 x P02 to the delivery and validate it
4. Go back to the SO
Error: Another picking has been generated, it's a return for P02. This
picking should not exist.
When validating the picking, because of the new line, a sale order line
is created with a quantity equal to 0. During the SOL creation,
`_action_launch_stock_rule` is called and checks if a procurement must
be created and processed. To do so, it checks if the SOL quantity (0 in
our case) is the same than the procurement quantity (1 in our case):
https://github.com/odoo/odoo/blob/6a0cbff92141961655a5f3e33abc23a2c5b1045d/addons/sale_stock/models/sale_order.py#L543-L549
Since the values are not the same, a procurement is created and
processed.
The feature that updates the SO when adding some products to the picking
has been introduced by 1f0835a9d01b46b5cc617756f854c25541b644a7 and is
correctly working in 14.0 because the condition (in
`_action_launch_stock_rule`) is not the same:
https://github.com/odoo/odoo/blob/ec5475ee881c5ca2bcc992592bfa4edf12f492df/addons/sale_stock/models/sale_order.py#L572-L574
In 14.0, we check if the SOL quantity is greater than the procurement
quantity. The condition has changed in 15.0 due to a new feature
(bda3225c6cc27bb2c2933eda3cc68c6f9708daf3).
ISSUE 02
When delivering more than sold, a useless SM is generated.
To reproduce the issue:
1. Create a consumable product P
2. Create and Confirm a SO with 3 x P
3. Deliver 5 x P
Error: A new line appears (Demand: 2, Done: 0)
Because the delivered quantity is more than expected, an extra move is
created. Then, the extra_move is merged into the initial one a condition
is respected:
https://github.com/odoo/odoo/blob/6f2ba1e1b40a458e23c8ed712927c44d75d86614/addons/stock/models/stock_move.py#L1603-L1610
Here is the issue: the field `date_dealine` is not copied anymore (see
[1]). Therefore, the condition will never be respected
[1] fb781dcf57
OPW-2716309
closesodoo/odoo#85649
X-original-commit: fabc32c4733bb404e74dc111d80aa1fe1edd4bfb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Changes made in the commit 27bd6a681037d2794dac2453d7064be3a8d5bb36
apply a white background in every tables and create visual issues
(e.g. the `o_inspector_table` on the right in `documents`).
This commit removes this global rule and applies a `bg-white` only to
the pivot view.
task-2731553
closesodoo/odoo#85642
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Reorder smart buttons on the hr_employee to have them in the following order:
1. Documents
2. Holiday status
3. Time Off
4. Planning
5. Timesheets
6. Equipments
7. Cars
8. Contracts
9. Appraisal
10. Work Entries
11. Payroll
12. Attendance
13. Extra Hours
- Log in the chatter the name of the plan that has been started via the button "Launch Plan"
- When on mobile, open the Time Off Calendar in month view
- When sending a sms without any message, only display Message once in the invalid fields
- Avoid the sms-help info disappearing when clicking on it and there are characters in the body of the message
- Update the tooltip of phone number in the send sms wizard
- Avoid the employee name to be displayed on two lines on mobile if the name is too long. Reduce the font size instead
task-2735679
closesodoo/odoo#83745
Related: odoo/enterprise#23886
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Part of the overall v16 SCSS optimization/restyle (task-2704984).
Additionally, this commit will fix the border-radius of modals that
should be rounded in community.
task-2734531
closesodoo/odoo#83128
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
The public read_group method is used by back-end code as well as RPC calls to receive grouped data.
Most of the time, if the data isn't shown to the user, it doesn't need to be sorted on the names of
the many2one, and can just be sorted on their ID instead, avoiding extra joins in the resulting queries
This is a first commit that will reduce the features of _read_group to the strict minimum necessary
to obtain correct grouped data that is never shown to a user
Task-id: 2479334
Part-of: odoo/odoo#84908
Adds a test that verifies that the grouping with a date aggregate
specifier (the only group specifier supported until now) is working correctly
Part-of: odoo/odoo#84908
reshape a bit the read_group tests by ensuring that:
- creation of user is made in batch
- assertions are always assert(actual, expected)
Part-of: odoo/odoo#84908
If a landed cost is validated for an invoice where items either have 1)
a zero value, or 2) have been partially reconciled multiple times until
it is fully reconciled, validation will fail with a cannot reconcile
error because they are already reconciled.
The fix is to use the `reconcilled` attribute rather than checking for
existence of `full_reconcile_id`.
X-original-commit: 608ed487b61c81e38a5d0b856732a8b94c6df64a
Part-of: odoo/odoo#85621
The FieldWrapper and the owl compatibility layer aren't bullet
proof. They allowed us to write new fields in Owl and use them
below legacy views, but in some tricky situations they can produce
undesirable race conditions. In particular, the FieldBooleanOwl
sometimes produces a crash in tours, making runbot builds fail
randomly.
This commit makes a special case for "boolean" when determining
which field widget/component to use: we always take the legacy
FieldBoolean, s.t. the FieldBooleanOwl is no longer used in
views. This is obviously not the perfect solution, but those
issues are really hard to reproduce in practice (it's rather
a concern for tour tests). Moreover, that FieldWrapper/compatibiliy
layer architecture is about to be removed anyway, as we are
rewritting everything with a top-down approach, including views
and fields.
Runbot build errors: 2158 3232
closesodoo/odoo#85573
X-original-commit: f74f81543c1d899dbb0dc201d26a460fb8ae61ac
Related: odoo/enterprise#24869
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
According to [1], the update function can be called before the tip
is rendered (i.e. when this.$el is null). [1] aimed at preventing
that function to crash when called in that situation. However, if
the function _delegateEvents is called and this.$el is null, it
crashes as well. This was a cause of non deterministic runbot
failure.
[1] a34cd7c662
Runbot build error: 3382
X-original-commit: 66dd147eb6d0aab10bf4d8883fa4965b76f55de8
Part-of: odoo/odoo#85573
Before this commit, it could happen that the trigger element of a
step was in the DOM at time t0, but was no longer in the DOM at
time t1, when we tried to actually execute the step, because of a
non zero running_step_delay. This commit checks again the presence
of the trigger in the DOM at t1, and if it isn't resets the step.
The same reasonning applies to the ui blocked check: we never want
to run a step if the ui is blocked.
X-original-commit: 119d509feb2cb93c648160af2848146e9c623e21
Part-of: odoo/odoo#85573
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit the industries were only matched on starting with or
containing the searched term and the autocompletion results were shown
alphabetically.
After this commit the industries are also matched if they contain all
individual search terms.
All terms are matched against the label and each synonym (if any exists),
but the industry is only displayed once, with its label.
If there are 7 results or less, the results are alphabetically sorted on
the label, otherwise the IAP result order is kept (which is expected to
be by descending cross-theme total hit count).
The truncation of the matching list to 15 results gives higher priority
to labels with the least words (so that "restaurant" still appears even
if there are 15 more common sub-types).
task-2688878
closesodoo/odoo#82018
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Usecase to reproduce:
- 2 product A in stock
- Deliver 1 the 1/1/2022
- Deliver 1 the 4/1/2022
- Deliver 1 the 2/1/2022
Current behavior:
Check Availability the 3 pickings at once. The 2 first are reserve
Expected behavior:
The picking for 1/1/2022 and 2/1/2022 are reserve
It happens because the sorted is only done on date deadline
opw-2762223
closesodoo/odoo#85584
X-original-commit: fb3b261ef56a62e2c753191313682287aa3a12fb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Purpose:
Allow users to make sure they will get an answer to the questions they ask
attendees while they register.
e.g.:
- You organize activities for kids and want to make sure you have a second
phone number available in case of emergencies
- You organize B2B events and need to know in which industry your attendees
work
- You use the Event/CRM bridge and plan to filter attendees based on those
answers
...
Specifications:
In the question form view, a boolean "Mandatory Answer" has been added.
In the list view, that field has been added as column.
In the registration form:
- "*", next to each mandatory question has been added
- "*" has been added next to name and email which were already mandatory
- the mandatory question have been actually made mandatory by preventing
user to submit empty answer
Remark: once_per_order was missing in the list view of the event template
questions. We have added it as well as "mandatory answer" field. The
question list view of the template and the event are now almost identical
(the button to the stat is obviously not present in the template).
Technical remarks:
- To ensures that multiple choice answer are filled by the users, we have
added an empty choice selected by default which forces the user to choose
one option.
- Empty answer were already filtered by the server and not inserted in the
database (in controller method _process_attendees_form, value evaluated
to false are not inserted)
Task-2745835
closesodoo/odoo#83586
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Nicolas (vin)