When printing a check from a payment the check number wizard shows the
number 1 for the next check... it should show the last check added one
+1, it doesn't because it doesn't exclude the account.payments without
checknumber.
This fix excludes the account.payments without checknumber so that it
doesn't shows "1" as the next check number when there are multiple new
checks to be printed
X-original-commit: adfb8299141cb8fe9883741c43871a51f849655e
Steps to reproduce the bug :
- Go to accounting > Configuration > Reconciliation Models
- Create a new reconciliation model
- Select the “Match existing invoices/bills” type
- In the field “Match Invoice/bill with” choose “Label”
- Add a new partner mapping > encode in "Find text in label" an erroneous regex like “*test” > choose any partner
- Go to accounting Dashboard > click on “Bank”
- Create a new Bank statement> add new transaction without selecting “Partner”
- Post the created bank statements > Reconcile it
Problem :
An error is triggered because the regex is wrong.
opw-2473973
closesodoo/odoo#68755
X-original-commit: cd9c071c9357cef14635ef094a9f14fc5431956c
Signed-off-by: William André (wan) <wan@odoo.com>
Demo data is not usually updated. It was also deleting the demo data
when doing a `-i account` when the module was already installed (or
actually the chart of accounts instantiated)
closesodoo/odoo#68802
X-original-commit: 8e4b7db8fe9f7c7cef1939938e9fa3df0dddc1f4
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When using "Generate Missing Terms" we export all translations and
reimport them with `create_empty_translation` so they empty translation
are made available.
But since we export all modules in the same PO file, the same terms that
might have different translation in different modules would get the same
translation value after using "Generate missing terms" which is
unexpected => usually we import/export PO file by module and so a term
translation is unique for one module only.
With this changeset, we import translation module by module.
When testing speed of Generate Missing Terms with 90 modules and 37000
translations, the timing taken change like this:
- original code: 21 seconds
- exporting/importing 1 PO file per module: 45 seconds
- exporting 1 TGZ file total/importing 1 PO file per module: 23 seconds
opw-2439029
closesodoo/odoo#68801
X-original-commit: 240de08ac8f5dbd2e263a48fea859605770f82a3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- On accounting settings, activate 'Cash Basis';
- Select a 'Base Tax Received Account';
- Modify a purchase taxes, and set the 'Tax Due' to 'Based on Payment';
- Set a 'Cash Basis Transition Account';
- Be sure that the previously selected account allows reconciliation;
- Create a Vendors Bills, using the modified purchase tax;
- Register a payment;
- Reset to draft the vendors bill.
Before this commit, an error was raised : 'Record does not exist or has
been deleted.'
This occurs because when trying to unlink the partial reconcile, it will
first reverse and unlink the tax cash basis partial reconcile moves.
After when trying to access the partial reconcile to unlink the error is
raised because one is already unlink.
Now, the vendors bill is correctly reset to draft.
opw-2477526
closesodoo/odoo#68754
X-original-commit: 72c29b105bdb4da5b306cd3b48a1683c1bf3e620
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
CRM install query count can vary from one execution to another, leading
to difficulties when analysing performances evolution.
The main reason for this is that some compute methods were called in
different order. Even if compute order shouldn't have any effect on the
final result, making it well defined will help finding other causes of
non-determinism.
The initial observation was that sorting Environment.fields_to_compute
leads to a fixed number of query when installing crm.
The main cause of non-determinisim is the usage of `set` impacting
Field.compute_value and BaseModel._modified_triggers.
Transforming all these `set` to `OrderedSet` solves the problem.
The query count is now deterministic when installing a database from
scratch, but not when updating a database with -i crm.
OrderedSet is also slightly optimised by using a dict instead of an
closesodoo/odoo#68692
Ordereddict: dict order is deterministic since python3.6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The website is now referenced to Odoo's website, with the most updated documentation.
closesodoo/odoo#68760
X-original-commit: 1488d0a06b4cc759f7432aa48023cc238701e953
Signed-off-by: Josse Colpaert <jco@openerp.com>
For b2c invoices we mustn't show the IVA information on the reports
closesodoo/odoo#68758
X-original-commit: 4e31502f317fabc2004bd6db32883ce357563c57
Signed-off-by: Josse Colpaert <jco@openerp.com>
Distinguish and display to the speaker which info is collected by the form
for internal use vs external dissemination. The contact details one wants to
share with the event manager (Private details : contact_phone, contact_email)
could indeed be different from the ones shared to attendees (partner_phone,
partner_email,...). The form in both back-end and front-end is made more
detailed, including more fields. Previously the form could have several
speakers, now only one.
Front-End
- Track proposal form changed, now includes tags, contact / speaker info...
- Track name and description are mandatory fields
- User can select (but not create) several track tags from those existing.
This allows categorizing the track in pre-defined categories with format
"tag category : tag name". It requires a select2 widget,
implemented in new file website_event_track_proposal_add_tag.js.
- New tickable section "contact me through different contact" not displayed
if the checkbox is not ticked. If the section is ticked, then the info set
there (contact_name, contact_phone, contact_email) will be added on a new
contact with id partner_id set on the track.
- In both cases (checkbox on/off), if the contact/partner email is the
same as logged user's, uses its partner on form. No contact creation needed.
- Improved / dynamic error display on form submission. If the form is valid,
it resets after submission.
- New widget in website_event_track_proposal.js:
- The partner_name is propagated on contact_name on input but editable.
- When the optional section is checked:
- The contact_name is made required.
- The user must at least enter a contact phone or an email. The email
is normalized but any phone format is accepted, since the choice of
country is not resolved (e.g. geoip not always relevant). Could be
improved with international phone number widget, see COM PR #34725
Back-end: following changes are done to ease contact creation and form completion
from back-end, as well as reaching the speaker from chatter
- On the form:
- If created on the fly from M2O (entering a name and using "create ..."),
the new partner will use default values contact_phone and contact_email.
- Once the contact is set (partner_id), contact_phone and contact_email
are set to readonly since they change according to the partner.
- When setting or changing the partner: this will fill all the form fields
with new available partner data to ease the flow, but only the empty ones
(this prevents losing previously entered information).
If partner is a company, company name is set to the name of partner.
- All fields are editable in the speaker section.
- Exception thrown if no contact mean available when supposed to.
- On the chatter, about contact creation and message subscription:
- From contact creation through suggested contacts.
- If the partner is set but is not in the followers, it is suggested
- If no partner is set, then there is at maximum one suggested contact
from track data: using contact_email if there is one, partner_email
otherwise. This priority serves main commit purpose. The user can
create and edit a corresponding contact if the address is not linked
to a partner. It will then be searched for and set on track.
Modifies tests in test_track_partner_sync. Before, partner fields on track
would be erased by customer's ones. Now, they are updated only if empty.
Contact fields are erased by customer's ones if set. tests changed accordingly.
Task ID - 2329406
COM PR odoo/odoo#60847
UPG PR odoo/upgrade#2346
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
On website app installation and on new website creation a configurator is launched.
The purpose of this configurator is to generate a website that meet the user's needs.
The configurator is composed of 4 steps:
1) Business description: the user is asked to describe its need with its website purpose (dropdown), its industry (autocomplete search) and its objective (dropdown).
2) Logo and palette selection: the user must select a color palette for its website. He can also upload its logo. In this case color palettes recommendations are generated based on the logo's colors.
3) Features selection: the user select the pages and applications he needs.
4) Theme selection: three themes are recommended to the user based on its industry. This screen display a preview of these three themes.
task-id: 2451965
ENT PR: odoo/enterprise#16949
UPG PR: odoo/upgrade#2316closesodoo/odoo#67537
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Mobile browsers implement their own floating toolbar in text selections.
As a consequence, Odoo Editor's floating toolbar ends up mingled with
the native one, making it hard to use.
This commit, in conjunction with adaptations on Odoo Editor's side,
replaces the floating toolbar on mobile devices with a static toolbar on
top of the editor and adapts styles accordingly.
Some instance options of Summernote remained in the code after replacing
Summernote with Odoo-Editor. This removes them as they effectively did
nothing.
Bug
===
If 2 partners have the same weight, the first partner will
have 2 times more chance to be chosen.
Task 2246367
closesodoo/odoo#67992
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
[IMP] event_*: clean ACL and add a new group "Registration Desk" …
Purpose
=======
Clean the ACLs related to the Event application.
Add a new group to manage the registration in the entrance of an event. This
group should not be able to modify or remove records in Event but should be
able to create and manage the registrations.
Specifications
==============
Now, there are 3 event groups
* ``Registration Desk User``, who can manage the registrations and
read all event-related information;
* ``Event User`` who can create event, sponsor, ticket... His role is
to globally handle events on a day-to-day basis;
* ``Event Administrator`` who can create event type, sponsor type,
ticket type... His role is to manage the way events are managed withint
its company:
Each group implies all previous groups.
Improve front-end so that event users can now perform some daily
operations directly in website, like publishing events or tracks.
Compared to previous event users gain a lot of rules, allowing to update
records like tickets, registrations, ... Low-end event users should now
use the registration desk group.
Links
=====
Task ID-2204364
COM #57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Before, the Event Manager could make some action on the frontend size,
like joining full meeting room, see unpublished track...
Now, the Event User has more permissions and can create Event, Track...
So, we want also to change the logic on the frontend side and allow him
to do the same actions as the Event Manager.
Task ID-2204364
COM odoo/odoo#57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
Event users cannot unlink registrations. To help them in their daily job
we added an active field on registrations allowing to archive them
without unlinking them.
Task ID-2204364
COM odoo/odoo#57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
Purpose
=======
Clean the ACLs related to the Event application.
Add a new group to manage the registration in the entrance of an event. This
group should not be able to modify or remove records in Event but should be
able to create and manage the registrations.
Specifications
==============
Now, there are 3 event groups
* ``Registration Desk User``, who can manage the registrations and
read all event-related information;
* ``Event User`` who can create event, sponsor, ticket... His role is
to globally handle events on a day-to-day basis;
* ``Event Administrator`` who can create event type, sponsor type,
ticket type... His role is to manage the way events are managed withint
its company:
Each group implies all previous groups.
Compared to previous event users gain a lot of rules, allowing to update
records like tickets, registrations, ... Low-end event users should now
use the registration desk group.
Links
=====
Task ID-2204364
COM odoo/odoo#57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
The purpose of this commit is to improve the repairs module general
workflow, to make it more intuitive and more flexible.
1. Change in the way the Repair Reference is created. It is now always
autogenerated. A new Repair Description can be used.
2. Make the 'Parts' and 'Operations' tabs editable up until (and
including) the stage 'Under Repair'.
3. Make the 'Lot/Serial Number' Field non mandatory for tracked
products, up to and including to the stage 'Under Repair'. If the
user forgot to specify the serial number and clicks on 'End Repair',
shows the exisiting error message.
4. Add product moves related to the repair order in a smart button at
the top right of repair, just like for a finished manufacturing order.
5. Add a Sale Order field in the repair form to make it easier to
perform return if needed.
6. When a component is not tracked by serial/lot number, leaves lot/serial
number read only.
7. Separationo of notes and internal notes into 2 seperate tabs.
8. Lot/serial field always visible but readonly when no tracking.
Task ID-2424420
closesodoo/odoo#66496
Related: odoo/upgrade#2327
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
=======
Propose an import tool that is more intuitive and allows more import options to
ease the import.
Specifications
==============
Update upload import file screen
--------------------------------
- Relabel import welcome screen
- relabel the 'load file' button to 'upload file'
- relabel the first (bold) line of the helper to 'Upload an Excel or CSV
file to import'
- Move all import options in a left panel
- Invert rows and columns in the mapping view
- One row for each column (header) to map in the imported file
- Columns: File Column / Odoo Field / If a match cannot be found / Comments
Left panel details
------------------
The sidepanel to the left of the mapping view is composed as followed:
- Imported File
- Import file name
- Sheet: Dropdown to select the sheet in the file if there are more than 1.
- 'use first row as header' checkbox: like the existing option, defines
whether the first row of the file should be considered as the header.
True by default. If False, display the first value only under 'File Column'
(see above)
- Formatting: only available if the file is a .csv
- list every option that already existed in previous import implementation.
- Batch Import
- is only available in debug moide and if the file exceeds the batch limit
- Batch limit : 2000
- Allow to define the threshold and the batch size.
- Help
- Download Template link
- Go to FAQ link
- Advanced
- Track history during import. (same as existing functionallity)
- Show Fields of relation fields. (same as existing functionallity)
Columns details
---------------
- File Column:
- Contains the column headers of the import file and the first non-empty
value of the column as a 'subtitle' (in grey italic)
- If 'use first row as header' is False, only display the first column value
(without the grey italic)
- Odoo Field:
- Contains dropdowns to the fields of the current model
- Required fields are diplayed in bold in the dropdown
- Icon: In the front of the field label, the field type (char, many2one,..)
is indicated by an icon.
- Tooltip: when hovering a field, display a tooltip with the following
information: field label, technical name, type, related model (if any)
- Placeholder: If no field is selected, display the placeholder
'To import, select a field...' in text-warning bold (i.e. orange)
- Allow clear: there is a close (fa-times) icon at the end of the dropdown
body to remove the Odoo field (and prevent import of this column)
- Multi Mapping: when setting a field already matched to another column,
unset it from the 'old' column (NB: exception made for char/text fields)
- Comments:
- Contains feedback from the system to the user, either import
errors/warnings or any additional details (multi mapping comments,...)
- For many2many field, display in related comment cell the following:
"To import multiple values, separate them by a comma".
- If there is an import error for a specific field, the error will be
displayed in the comment cell of the related field.
- If there is a mapping error, mapping options are displayed under the
error div to let the user choose the best option to fix that error.
Import errors management
------------------------
- Errors/warnings that can be matched to a specific field are displayed as
alert-danger/warning in the corresponding 'Comments' cell of the field.
- For 'no match found' errors, if X values couldn't be found,
display an unique error box will all the errors.
- Values beyond the first three are folded under a 'More' button.
- No changes on the 'See possible values' button.
- If an unmatched value is present in one row only, display :
'<value> at row X (<name of the row if the name field is matched>)'
- If an unmatched value is multiple rows, display:
'<value> at multiple rows'
- Errors/warnings/infos that cannot be matched to specific field are displayed
above the mapping listview. Global errors are not regrouped by error types to
avoid too much code complexy just to handle the rare times where multiple errors
of same types cannot be linked to a specific mapped field.
BaseImportError class have been introduced to ease the formatting of the various
exceptions that can occur during the import.
After testing the import, display the following above the mapping table:
- No warning/error:
'Everything seems valid' (alert-info)
- At least one error:
'The file contains blocking errors (see below)' (alert-error)
- At least one warning but no error:
'The file contains non-blocking warning (see below)' (alert-warning)
Mapping options
---------------
Mapping options are only displayed after testing or importing the file,
if there are import errors. The goal is to have a clean interface and to guide
the user step by step. The import process can therefore be a bit longer as it
needs to import -> choose solution for errors -> re-import but that is easier
for users to learn and understand this reworked import tool.
Possible values when a value cannot be matched:
- For many2one / many2many fields:
- Prevent import: (selected by default) not finding a match is blocking the
import
- Skip unknown values: values that cannot be matched will be skipped.
(hidden if the field is required)
- Create new values: Create records for values that cannot be matched
- For selection fields:
- Prevent import (selected by default)
- Skip unknown values: (hidden if the field is required)
- Set to <first value>: if cannot be matched, set it to <first value>
- Set to <second value>
- Set to <third value>
- etc.
- For boolean fields:
- Prevent Import (selected by default)
- Set to True
- Set to False
Note: With this rework, boolean warnings where the system assumes the
replacement value in case of matching error is removed and is replaced by a
blocking error. The user now has to choose the value to set.
"Prevent import" is the default behaviour when testing or importing.
Automatic mapping proposal
---------------------------
When loading a file, an automated mapping is directly proposed to the user,
based on word distance (see below), and on mapping created on previous
imports.
- Priority is given for mapping created on previous imports, skip fuzzy mapping.
- a distance of -1 is used to ensure priority during duplicates removal .
- In case multiple headers are mapped on the same field, if the mapped field
is already taken by another header, use fuzzy mapping instead.
- If no previous mapping for that header on that model, try an exact match on
every field id and field name of the model. (distance = 0)
- If no match is found, fuzzy mapping is applied (word distance).
The fuzzy mapping is executed only on the most likely fields (see below).
- Remove duplicates: keep the header-field couple that has the smallest
distance. In case of equality, keep the first.
Automatic mapping is therefore optimised for previous mapping or exact match,
as fuzzy mapping requires heaviest treatment. This is intended to prioritise the
import of files based on import templates.
Most likely fields
------------------
When parsing the import file, each header is analysed to guess what type of data
the column contains. For example, ff the column contains float, we suppose that
that header will most likely be matched on float or monetary fields.
The most likely fields are a subset of the model's fields that match the
header types.
Most likely fields are used for the fuzzy mapping, to propose the user a field
mapping based on the header types, if an exact match could not be found.
Most likely fields are also listed under "Suggested fields" in the mapping
dropdown in "Odoo Field" column of the import tool.
For now on, every fields (no mather their type) can be matched to any header,
but we prioritise the most likely fields. This way, we don't constrain the
mapping possibility based on what we suppose the user would do, but we instead
guide suggest the user the most likely mapping solutions.
Word distance mapping
----------------------------
In order to improve the mapping configuration, if an exact match cannot be found
between the file column and one of the odoo field:
- Use Word distance:
Word distance return a indice between 0 and 1.
- 0: exact match
- 1: completely different
- A: First try on field['name']
- B: Then on field['string']
- Keep the minimal distance between A and B for each odoo_field
- C: Keep the field that has the minimal distance.
- Match the column to the field by default if C['distance'] < 0.3.
Note: 0.3 has been chosen to ensure proximity but still having a little
error margin.
Multi mapping
-------------
When multiple file columns are matched to the same char/text/many2many field,
display the following alert-info box in the "Comments" column of the related
fields:
"Those columns will be concatenated in field <field label>"
Multi mapping rule :
- If it is a char field, separate the concatenated values by a space
- If it is a text field, separate the concatenated values by a line break
- If it is a many2many field, separate the concatenated values by a comma
Various improvements
--------------------
- During Import (or Test), the first waiting message displayed has been modified
to 'Importing...' or 'Testing...'. The progress (x record imported/tested) is
only displayed after the first batch of record have been imported/tested.
- Ease matching for Selection field: use case insensitive comparaison instead
of exact match.
- Add filename to import wizard.
- Add placeholder to search input of field mapping dropdown.
Tests have been adapted accordingly.
Links
=====
Task ID: 2352241
closesodoo/odoo#61948
Related: odoo/enterprise#17246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- The test was clicking on a link "too soon" in some cases (editing a
link then immediatly clicking on it while the save action is not fully
performed). Ideally, this should probably be more robust around the
save action to first edit the link synchronously then perform the
actual save in DB but this can be checked later on.
- Removed useless popover update while it was hidden.
- Make sure that two consecutive update of the popover only updates its
UI relying on the last asked data.
- Make sure the popover correctly clean what it did once destroyed
(however, it is never actually destroyed for now... to check later).
closesodoo/odoo#68686
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Account move view improvement and creation of amount_total_in_currency_signed
to allow display of amounts in company currency and in move currency.
closesodoo/odoo#66069
Task: 2403336
Related: odoo/upgrade#2331
Related: odoo/enterprise#16308
Signed-off-by: William André (wan) <wan@odoo.com>
The Payment form view is simplified for a much less cluttered screen.
A paired internal payment is now created when an internal transfer is posted.
Task: 2403336
Before, when the user clicked on a crm opportunity "meetings" smart button,
the calendar view was centered on the present day, and with default mode
(week, month,...) as a scale. This behavior leads to calendar views that
were possibly not including those meetings.
This smart calendar improves this by computing the target date and the scale
to make sure that the user is taken to the useful time period when using the
smart button from crm opportunity. The meetings considered are only the
relevant one, that is only the ones not finished yet, if there are some, and
all (finished) meetings otherwise. The calendar works as follows :
-If no meetings: show current week
-If one: show that week
-If more than one and same week : show that week
-If more than one and same month : show that month
-If more than one month, show month of the first meeting.
This is done according to user language week_start and timezone. This way
the user always see what is the most relevant.
Also added python tests in class TestCRMLeadSmartCalendar.
Task ID-2431245
closesodoo/odoo#64807
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A domain with a negated thruty leaf raises an exception here
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L614
due to
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L670
and the fact that `FALSE_LEAF != (1, "!=", 1)` and `TRUE_LEAF != (0, "!=", 1)`
Current wrong behaviour:
```
>>> distribute_not(['!', TRUE_LEAF])
[(1, '!=', 1)]
>>> is_leaf((1, '!=', 1))
False
```
This issue was noticed when adapting domains for fields that have been
removed during migration. Example (extract of) traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/13.0/odoo/http.py", line 624, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
...
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 677, in __init__
self.parse()
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in parse
self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in <listcomp>
self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 562, in __init__
self.check_leaf(internal)
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 618, in check_leaf
raise ValueError("Invalid leaf %s" % str(self.leaf))
ValueError: Invalid leaf (0, '!=', 1)
```
closesodoo/odoo#68665
X-original-commit: e20c23658d15a135e5f35b0e8dec6e3202cecaab
Signed-off-by: Christophe Simonis <chs@odoo.com>
This commit is needed for the enterprise PR linked below.
It will be needed to notify followers if a calendar event
gets cancelled (archived)
LINKS:
TaskID: #2223519
Community PR: odoo/odoo#68022
Enterprise PR:odoo/enterprise#17141
*: website_sale_comparison, website_sale_wishlist
Redesign the all products page (/shop) + various UX improvements
task-2009483
Part of #66736
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: portal, portal_rating, product, sale, sale_product_configurator,
website, website_sale_comparison, website_sale_product_configurator,
website_sale_stock, website_sale_wishlist, point_of_sale
Redesign of the product page + various UX improvements.
task-2009483
Part of #66736
After this commit, the image of the product is in position sticky so
that it remains displayed while scrolling the right column.
task-2009483
part of #66736
This field was not very informative to the user; plus there is now a widget checking the account type with a little icon next to the field containing it.
Task 2412391
closesodoo/odoo#65227
Related: odoo/upgrade#2121
Signed-off-by: William André (wan) <wan@odoo.com>
Adding this field to the bank journal's form view had been done to ease encoding; yet more fields were left to be set on the related res.partner.bank object (l10n_ch_qr_iban, chf and eur subrscription numbers. In the end, to be consistent, we would have needed to do related fields for all of them as well on the journal. This would have put too many advanced features in a single screen. Instead, we just consider the whole setup needs to be done directly on the res.partner.bank.
Task 2412391
This way, the bank account can be easily and immediately configured so that QR-codes can be generated on invoices without any additional setup (for Switzerland and SEPA).
This configuration step is hidden if full accounting features are enabled, since it will then appear in the "main" setup bar, on the dashboard.
Task 2412391
This module had been introduced in stable to add a field to store the QR-IBAN in case it differed from the regular account number. We now merge it into the original module and make it so that the only way to define a QR-IBAN is to populate this field (no more magic with account number).
Purpose
=======
Avoid creating / enriching multiple time the same company.
It can occur in many situation; when IAP do not return an email address
the the company, when the domain is blacklisted...
We also want to remove the field "iap_enrich_info" from the res.partner
model because this field can be heavy (JSON field) and the res.partner
model is used a lot.
Technical
=========
For this purpose, we create a new model <res.partner.iap> which will
store the IAP response and the requested domain.
So we can retrieve the previously enriched company regardless of the
partner's values
Task 2466653
See odoo/odoo/pull/68286
See odoo/upgrade/pull/2301
closesodoo/odoo#68286
Related: odoo/upgrade#2301
Related: odoo/enterprise#17426
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- fixes some typos
- adds command parameters which are present when running odo-bin --help
- updates some descriptions, e.g. regarding configuration file and data-dir
closesodoo/odoo#67778
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In belgian accounting, some tax lines in the tax report must be carried
over to the next period if they are negative.
If the balance for the next period is positive, it will be deduced by
the maximum possible amount that is carried over. If it is negative,
the negative balance will simply be added to the carried over balance.
This process repeats itself from one period to the other endlessly,
until the carried over balance come back to 0.
This is done by putting the carried over balance in dedicated analytic
accounts.
task id #2271978
Andres Calle