In a grouped kanban view with progressbars, click on a progressbar
to filter a column, and then click on the "+" icon of that column
to quick create a record (e.g. in a project). Before this commit,
the buttons ("Add", "Edit" and trash icon) overlapped the bottom
of the card.
This is due to special rules applying when a progressbar filter is
applied. Those rules aim at grouping non filtered out cards on the
top, s.t. the other ones (e.g. a dragged&dropped card) are displayed
below.
It was decided that this grouping isn't really wanted anymore. For
instance, it could lead to weird UX if the filtered column contains
a lot of records, as the dropped one would appear at the bottom,
i.e. would not be visible for the user.
This commit thus simply removes those rules, which fixes the issue.
closesodoo/odoo#108396
X-original-commit: 69fa3654e479f427606d05cdb244fd24225f9eeb
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
When the user exports the note records, an error is raised because the
'__count' key does not exist in the result of the 'read_group' method.
Steps to reproduce:
------------------
- Go to the Notes
- Click on the list view of notes and filter group by Stage.
- Click on the export all button to print the excel report and see the
error.
Expected behavior:
-----------------
The data should be exported in `csv` file.
Current behavior:
----------------
An error is raised when the user wants to export the data.
closesodoo/odoo#108394
X-original-commit: 3bd979421744a11b6f10c95f47cf378720079ffb
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
In Email Marketing's Mail Body, The Powerbox is opened below the cursor,
even when there's not enough space between the cursor line and
the window's bottom. As a result, a part of the Powerbox cannot be seen.
After this commit:
Now, the Powerbox opens itself above the cursor line if it's too close to the
window's bottom.
Task-3037435
closesodoo/odoo#108352
X-original-commit: ba888c39716f0226adce993cb08852e21b0376eb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds a step in the click all test: for each view, enter
and leave Studio, to ensure that the view doesn't crash in Studio.
With the migration of views to owl, a lot of views worked fine, but
crashed when entering Studio. Those issues have been solved now,
and we want to ensure that this no longer happens in the future.
closesodoo/odoo#107992
X-original-commit: d18310bddf0a4f741a6335e5499ab213fb046993
Related: odoo/enterprise#35054
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] introduced a "custom" type of button as the only type of
button whose background color we are allowed to change. But the option
to change any button's background color exists in mass_mailing so we end
up with the same option in two different places. This removes that
previously existing default option.
[1]: https://github.com/odoo/odoo/commit/a010c91b5ee119cf54ed1a68a6ea06b2bc5f3978
task-3096806
closesodoo/odoo#108269
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: website
The fields of a form that are mandatory because of the model they need
to be used in cannot be removed. When such a field is selected, the
remove button displays a tooltip giving this information.
Disabling the overlay button is done by removing the specific class -
which makes the event selector not linked to the button, but also
impacts the applied CSS rules.
This commit adds an `o_disabled` CSS class upon disabling the button.
The tooltip is put on a `span` that wraps the disabled button because
tooltips cannot be shown on disabled elements.
Steps to reproduce:
- Drop a "Form" block.
- Select the "Phone Number" field.
- The overlay's delete icon has a reddish background.
- Select the "Your Email" field.
=> The overlay's delete icon had a dark gray background instead of a
reddish one.
task-2950433
closesodoo/odoo#107864
X-original-commit: ed3acbae6a6b2fe91c948ceeb16a5bdb3fa8f060
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
With recent JS change on "group" the currency symbol was missing. By adding the currency_id field invisible in the arch the problem is solved.
Task-id:3089285
closesodoo/odoo#107106
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
- base.view_base_module_uninstall
- base.base_module_install_review_view_form
- base.base_module_install_review_view_form
were the only 3 views in which a node was set outside the
<form>, <tree>, <kanban>, ... node.
```sql
master-all=# SELECT name FROM ir_ui_view WHERE type != 'qweb' AND inherit_id IS NULL AND arch_db ->> 'en_US' not ilike '<' || type || '%';
name
---------------------------------------
Uninstall module
base.module.install.request.view.form
base.module.install.review.view.form
(3 rows)
```
These were introduced by odoo/odoo#99438.
The goal was to set these warnings on top of the form view,
with no margins for a better UI.
While this serves an understandable purpose,
not having <form> as the root node causes issues:
- First, as seen in the above revision,
it requires to have to specify the view type in the XML data file,
because the view type is guessed from the root node of the view
```diff
<record id="view_base_module_uninstall" model="ir.ui.view">
<field name="name">Uninstall module</field>
<field name="model">base.module.uninstall</field>
+ <field name="type">form</field>
```
- Second, in the view post-processing, some implementations
are based on the root node of the view,
and not having `<form>` as the root node for instance makes
the view not editable, or not pass the `readonly`, `required`
attributes from the Python model.
https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1146-L1147https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1375-L1379
We could use the view type from the model itself,
instead of the root node, to determine the type of the view,
but then you wouldn't be able to use attributes set on the view node,
such as `editable="1"`, to determine if the root/view node is editable
or not.
https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1352
Because the `<form>` node wasn't the root node in the uninstall form view,
the modifiers attributes (`readonly`, `required`) were not passed
from the field python model to the view,
and the Studio fields
`custom_views`, `custom_reports`, `custom_models`, `custom_fields`
were editable in the view, while they shouldn't as those
are readonly computed fields.
A constraint will be added in master, to prevent developers
to create views with as root node something else than the view type.
The constraint is not added in stable 16.0 to avoid to suddenly
raise a constraint exception for modules from the community
and customers in production databases.
closes#107947closesodoo/odoo#108319
X-original-commit: c9dd160242c55dc824d4300635528dc82309f599
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Remove the t-on-click used in form view as it crashes when
opened with studio.
Instead we use a dedicated "<widget/>"
task-3090960
closesodoo/odoo#106241
Related: odoo/enterprise#34235
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
1. Drag and drop the "image - text" snippet.
2. Click on the image => you have a double overlay which appears (one on
the column with handles and one on the image without handles), this is
good, that's what we want: the ability to control the column width but
as the image has options, it should be framed with an overlay too to
indicate what you are editing in the right panel.
3. Hover the column options => good, only the overlay of the column
remains in preview mode (without handles / buttons).
4. Hover the image options => good, only the overlay of the image
remains in preview mode (without handles / buttons).
5. Stop hovering the panel => the double overlay should be restored but
that's not the case: only the column one remains, even though the image
options are still displayed in the panel.
When we introduced the possibility to display 2 overlays at the same
time in this commit [1], we added a loop to search for the overlays to
display since there can now be several.
But in a later commit [2], we added a `break` in this loop, which no
longer allows displaying more than one overlay when necessary.
[1]: https://github.com/odoo/odoo/commit/9bbe5be3fb0d995374a369851df3641979d8e553
[2]: https://github.com/odoo/odoo/commit/806a8db35b5e0e6a461422f5bba7c97180c3ef29
task-2919164
closesodoo/odoo#108334
X-original-commit: ee86f5a94965ce691393f5300bdfb6dc09780b1d
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit: after calling the `init_from_JSON` of the order line,
the `pack_lot_ids` would be changed. It will cause a problem if this
function is called before sending the JSON to the backend or saving it.
The solution is to copy its value and prevent it from changing.
opw-3088922
closesodoo/odoo#108308
X-original-commit: 4f5f5750b05873f0ddce7fe862686202a2725563
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, some tag would not display correctly in the tag list of eLearning
This commit fixes this behavior
closesodoo/odoo#108286
X-original-commit: df1b22f23511ec82687d28a284ab8696fcd2aef4
Related: odoo/enterprise#35091
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Install invoice, go to any sale-order and print it. There are warnings
in the logs for a problem in the wkhtmltopdf subprocess and for 404
page not found for some css assets while rendering the document.
So the first pdf printed is invalid, but as the report is printed the
asset is commited in db and the next print will be valid.
If you use kwkhtmltopdf, as the pdf is not generated (kwkhtmltopdf is
more strict), then you have an error instead of a broken pdf and the
asset is not commit, so you printing is always broken.
Before #104594, the asset was commited at the end even if we had an
error.
closesodoo/odoo#108330
X-original-commit: 0fb8bcbae18027843583304460f1956ef2d2fe51
Signed-off-by: Julien Castiaux <juc@odoo.com>
Purpose of this commit is to add tests to check current behavior of composer
when he is updated with Falsy values :
* template set, with void value for some fields that may reset or not
existing composer values;
* template being set to False, check what happens with composer values
(kept or reset);
This may change in a near future but at least it will be documented.
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#108320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some tests are basically trying some combinations of composer parameters.
Currently only composition mode is a parameter but we will soon add the
batch mode, as it will be dissociated from the mailing mode.
To ease debugging, let us use subTests when possible, even if this creates
some diff due to the new indentation level to add.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#108320
Purpose is to cleanup and add some details in some tests, notably about
default values when using message_post wrappers with either a view or
a template.
Tests with void recordsets are also added to check their current behavior
and try to keep it consistent when cleaning code in a near future.
Add a missing mute logger.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#108320
Before this commit:
Thread details gave information regarding the database
the UID and the URL.
After this commit:
It also informs on the "performance times":
- `qc` = query count
- `qt` = query time
- `pt` = python time. It should in theory be "remaining time", but it won't be use as its acronym `rt` is too ambiguous/confusing
closesodoo/odoo#106610
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
mass_mailing had a special snippet option just for resizing images
horizontally. Since this exists in the website builder as well, there is
no need for a separate snippet with a different behavior for
mass_mailing.
task-2615373
closesodoo/odoo#84061
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Some people are confused because since 'always edit mode'
the alignments of the labels vary according to the groups.
This feature is wanted and the goal is to have the input as close
as possible depending of the largest label of the group (max-width: 150px)
to easily find it when you hover it.
We only keep the aligenment per ´o_inner_group´.
To reinforce this idea of aligned grouped fields, this commit adds
a margin-bottom to separate these groups.
in addition, it allows to better see the groups on mobile.
closesodoo/odoo#108311
X-original-commit: be9e1c666c3bb5aa36fb41a62783c6ecf01aa106
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, labels in a ´o_inner_group´ not wrapped in
a ´o_group´ had a margin-right of 5px while the other labels
have no margin.
it is probably an oversight during the refactoring because margins
are now managed by the grid system.
<group>
<group>
<field name="A"/>
</group>
<group>
[...]
</group>
</group>
<group>
<field name="B"/>
</group>
In this example, inputs of A and B were not aligned because
of the margin-right of label B.
X-original-commit: fb629dc91df1720cb0658d3e9f946a4fda83fbd0
Part-of: odoo/odoo#108311
An error is raised when trying to create sale order lines with tax on a
sale order without any customer (with debug mode enabled)
Steps to reproduce:
1. Install Sales
2. Create a new sale order without any customer
3. Add a new sale order line and a tax to this line
4. An error is raised `Invalid props for component 'TaxGroupComponent':
'currency' is undefined`
Solution:
Make prop `currency` optional (and format the total without any
currency)
Problem:
When trying to render the tax total of a sale order without any
pricelist, an error is raised as the `currency` prop is missing, which
depends on the pricelist
opw-3098020
closesodoo/odoo#108310
X-original-commit: c3acd369976f46e5c987d9d460908f99c6f05b0c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit fixes two things:
- The owl compatibility layer adds an `on` and `off` method on owl's
EventBus so that it can keep being used as it used to in owl 1. To do
this, it needs to keep track of the the callbacks that are attached to
it and by whom. To do this it keeps a Map where the "owners" are keys.
When calling `off` to remove event listeners, we remove the callbacks
but did not remove the owner from the Map, causing the EventBus to
always hold a strong reference to any object that was given as the owner
to the `on` method, preventing the item from being garbage collected.
Objects that do this are typically components, and components hold a
reference to their owl application that contains the entire tree of
components. This was particularly problematic in tests where components
are created and destroyed at a rapid pace.
- The mock websocket creates a MessageChannel so that it can mock the
server side of the websocket, but it never closes that MessageChannel's
MessagePorts, which can cause garbage collection to be slow to happen
[1] (in practice it looks like these are basically never garbage
collected unless closed). This commit registers a cleanup to close the
message ports after the execution of the current test.
[1]: https://html.spec.whatwg.org/dev/web-messaging.html#ports-and-garbage-collectionclosesodoo/odoo#108309
X-original-commit: 4facc396a4e8036592a473002253d5a5daf41a19
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit allows to specify a custom Compiler to be used by the
KanbanRecord of a custom Kanban view (js_class). This is necessary
for the social kanban views. Something similar is already done in
the Form view.
closesodoo/odoo#108221
Related: odoo/enterprise#35065
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In html, tags are case-insensitive. However, owl templates aren't,
as nodes starting with a capital letter are considered as component
nodes (not html). This means that people can use capital letters in
form or kanban archs for html nodes and it should work.
Before this commit, it didn't, because the compiler kept the case
when generating the owl templates. For instance, an arch like
`<form><Div/></form/>` produced the error 'Cannot find the
definition of component "Div"'. This commit fixes the issue.
Part-of: odoo/odoo#108221
Kanban and form archs aren't owl templates. Kanban archs define
a (historically) qweb template ("kanban-box") which is html + some
directives (e.g. t-esc, t-foreach...) and extra tags (field, widget).
Form view archs are html + some extra tags (e.g. group, notebook,
field, widget...).
With the conversion of those views to owl, a door was left open:
one *could* use owl directives (for instance, t-on-click) in archs.
However, we don't want people to do that, as it would tie the archs
in database with js implementation details, which will then limit
the evolution of the js framework.
This commit adds warning when such forbidden directives are detected.
In master, we'll raise errors.
Part-of: odoo/odoo#108221
pricelist report is not aligning properly in html and pdf print out due to offset class.
closesodoo/odoo#108278
X-original-commit: f392879a8dcdb50a62143e2aa37903164174179b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Only show the stress-days of the enabled companies.
task-3098721
closesodoo/odoo#108277
X-original-commit: 7fb96b24fd8ec65b58c43d223dc63c0068b6269a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When a leave was canceled, the overtime record linked to it was not
deleted resulting in a wrong count of available overtimes.
Whatever the config of the time off type used to deduct extra-hours, its
total should be displayed in "hours" instead of "days" on the dashboard.
task-3097259
closesodoo/odoo#108275
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Due to a recent change, the time off dashboard was not properly updated
when a leave was created/deleted/canceled.
task-3097259
Part-of: odoo/odoo#108275
This module implements communication with the fiscal device for
submitting invoices to the KRA (Kenya Revenue Authority). The device
supported in this module is the Tremol G03.
-- COMMUNICATION FLOW SUMMARY --
1. "Send Invoice To Device" on account move is clicked
2. l10n_ke_action_cu_post triggers a client action, with serialised
invoice data. (more details below)
3. The client action uses the 'post_send' function defined in javascript
to forward the request to the /hw_proxy/l10n_ke_cu_send endpoint on
the proxy server (more details below)
4. The proxy server wraps the serialised data with the appropriate bytes
(for instance, a couple of a checksum bytes), and sends them to the
device through serial communication (more details below)
5. The data returned from the fiscal device is communicated back in the
request. The client action 'post_send' then triggers the
'l10n_ke_cu_response' with an rpc call, with the aforementioned data
from the fiscal device
(more details)
2. The module l10n_ke_edi_tremol inherits from the account_move model in
order to provide methods for serialising the data of the account_move
and sending it to the proxy server. Fields have been added to the
product template to define the HS Code and HS Name (data which is
required by the KRA in some circumstances). A field has also been added
to the company defining the address of the proxy server. The fields
added on the account move are populated by the data returned by the
fiscal device, this includes the device serial number, the invoice
number on the device, the URL of the invoice on the KRA web portal, and
the date/time the invoice was signed.
3. Communication between the client database and the proxy server is
defined using a client action defined in
l10n_ke_edi_tremol/static/src/js/send_invoice.js. This allows users who
aren't on-premise to communicate with the device, provided the proxy is
accessible on the network that the user is on.
4. The proxy server is an intermediary server that should be connected
to the tremol G03, and running the IOT drivers from hw_drivers. The
driver that supports communication between the proxy server and the
fiscal device has been defined in this commit inside of
hw_drivers/iot_handlers/drivers//L10nKeEDISerialDriver.py.
The proxy server can be run on the IOT box, or on odoo community by
running:
./odoo-bin addons-path=.... -d dbname --load hw_drivers --proxy-mode
** all messages are encoded/decoded with cp1251, as defined in the
protocol. The company vat code is sent along with the request to compare
that sent with that of the device. The 'serial_number' of the device is
always returned along with the request, since it is required for the
invoice details, and it is retrieved as part of the query to find the
registered VAT code on the device.
--- DATA and VIEWS ---
product_view:
adds HS Name, and HS Code on the product product and product template
form views.
report_invoice:
adds to the invoice qweb template such that a section including the
fiscal device / KRA details is included at the bottom of the invoice
when the invoice is rendered as a pdf.
res_config_settings_view:
adds makes the proxy address field editable from the config settings.
account_move_view:
add a tab for the tremol device details and the qr code on the account
move form view. The KRA invoice number is also added as an optional
field on the account move tree view, and the invoice search view is
inherited to make this field searchable too.
(l10n_ke) account_tax_report_data, account_tax_template_data:
The tax report is defined for Kenya, and tax tags that link to the lines
on this tax report are defined on the existing taxes. This allows the
classification of the tax, between zero-rated and exempt, during the
serialisation.
closesodoo/odoo#106654
Task-id: 2950308
X-original-commit: b0be9e074a1ecf1f6de7a03c71df0c63868501e3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
The tests consist in sending a mail related to a record to a customer and
checking that the record can be viewed through the embedded link:
- either in the backend if the user is connected and has the right to
- or in the portal otherwise
It also test that if the embedded link is tampered, the access is forbidden.
Task-2797311
closesodoo/odoo#105405
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit [1] added a div around the `.note-editable` node of the html
editor. This broke some css rules. For instance, the html field in
form view's notebooks should have a transparent bottom border when
focused, this was no longer the case (e.g. crm lead form view).
Moreover, we sometimes want to control the height of the editor
(e.g. in Notes or in the mail full composer). That was broken as
well due to the added div.
This commit fixes those issues.
We also ensure to set the border-radius to 0 when the editor only
has a bottom border.
In notes, we do not want to have borders, but the rule didn't
apply due to selector precedence, we fix that as well.
Finally, we fix a typo in a selector in the web_editor addon.
[1] https://github.com/odoo/odoo/commit/60ac6be0d3545#closesodoo/odoo#107740
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behaviour:
Project Update doesn't take into consideration the `analytic_distribution`
percentage of the analytic_account on the line of the purchase orders.
Expected behaviour:
Account correctly for the % of the analytic account for the project,
just like in the Accounting app.
Steps to reproduce:
- Install Accounting, Sales, Purchase, Timesheet, Inventory, Project
- Activate "Analytic accounts" in Settings
- Create a product service which is creating a project at sales
- Create a new SO, add the service, confirm the SO and invoice
- Create a new PO, add some random product, on that same line add 2
analytic account, 50% of the SO project we just created, and 50% from any other.
- Confirm the PO
- Go to the SO's project update section, observe the cost is 100% of the line cost, not 50%
Reason for the problem:
`analytic_distribution` ratios are not taken into account when calculation the costs
of the project.
Fix:
Get the ratio of the `analytic_distribution` and multiply by it when processing the costs
Affected versions:
- 16.0
- master
opw-3079537
closesodoo/odoo#108222
X-original-commit: b676222c129863c154efb48e454e144b77157617
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This PR (https://github.com/odoo/odoo/pull/105748) introduced a bug
by having an extra `OR` operator in the domain.
This commit fixes the error.
opw-3099849
closesodoo/odoo#107889
X-original-commit: 1f496609ecd2a7afdac53f4a622895bbe5b6cb81
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Purpose
=======
Simplifying the mail modal used to share surveys
Specifications
==============
* We simplified the modal, you can hide all the parameters for the template creation
* The dynamic values are displayed as computed in the modal
task-2901947
closesodoo/odoo#100705
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since 2515482d5a70, the duration expected of a workorder was always set
to the real duration at the validation of the workorder. This commit
ensure the duration expected is left unchanged even if the
date_planned_finished is updated.
closesodoo/odoo#108233
X-original-commit: 46e1ae4d9918de1aaf6b4a7565dba422b03fcb36
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- [IMP] l10n_it_edi: Tax exemption kind N7 description
New specs from October 1st 2022:
https://www.doxee.com/it/blog/fatturazione-elettronica/nuove-specifiche-tecniche-per-la-fattura-elettronica-2022-in-vigore-dal-1-ottobre/
The description of Tax Exemption kind N7 is changed to:
"IVA assolta in altro stato UE (prestazione di servizi
di telecomunicazioni, tele-radiodiffusione ed elettronici
ex art. 7-octies, comma 1 lett. a, b, art. 74-sexies DPR 633/72)"
Courtesy of Tony Mascii
- [FIX] l10n_it_edi: San Marino self-invoice from paper
San Marino is a very small country completely enclosed in Italy.
That country has special agreements with Italian as far as
e-invoicing is concerned.
When a paper invoice is received from San Marino, any Italian
company has the responsability to submit that invoice integrated
with Italian tax information to the Tax Agency, indicating in the
e-invoice filling the Document Type field with the special value 'TD28'.
- [IMP] l10n_it: Round globally by default in Italian CoA
The Italian Tax Agency (and therefore any business in Italy)
makes it mandatory to compute roundings based on a Round Globally policy.
Invoices not rounded globally are refused by Italian EDI.
- [IMP] l10n_it, l10n_it_edi, l10n_it_stock_ddt: Deferred invoice
Context:
The Italian State allows making one invoice per month
to recurrent clients buying goods several times a month.
This process is called "Deferred invoice" (Fattura differita)
in contrast to Direct invoice (Fattura immediata).
To enable this, the vendor must issue one Transport Document
per client delivery. The Document is attached to the goods themselves.
Many Transport Documents (DDTs) delivered can then be invoiced together
in a single invoice up to the 15th day of the following month.
This task allows the Italian EDI to correctly communicate
the Deferred invoices data to the Tax Authority
An export test has been added.
Official FAQ (n.21) - https://www.agenziaentrate.gov.it/portale/documents/20143/287582/15+Tutte+le+faq+%28aggiornate+al+11+maggio+2021%29+.pdf/2db944b9-22c3-fa80-7c14-dfa0bcbbd65e
Reference task link: https://www.odoo.com/web#model=project.task&id=1914640closesodoo/odoo#108230
X-original-commit: 87dd99e8abd8281fd81164d1f007ceaff3123834
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
The method domain_remove_leaf is used to remove leaves from a domain
corresponding to given fields. The particular case ['|', leaf_to_remove,
leaf_to_remove] is replaced by [true_leaf] however the check of the
second element of this subdomain was incorrectly done. This fix
addresses this issue.
Fixes https://github.com/odoo/odoo/pull/93225closesodoo/odoo#108188
X-original-commit: 44578077b16b540a0270ea7257f902a2e917f79c
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the values of selection `service_policy` field are
given with a function and so the choices are dynamically given according
to the modules installed and the project settings. The problem is the
string for those values are not translated because the ORM cannot do
it automatically since the values are dynamically given and so
those string should be translated with `_` function.
This commit translates the string of those values with `_` function to
be sure the strings are translated in the language of the current user.
closesodoo/odoo#108154
X-original-commit: 90cf43789d849df3908f4636228cb643a005427f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, when we creating a tag, it does not appear in the Kanban
view because the tag does not have a default color.
This commit solve above problem by adding default random color in tag.
task-3089296
closesodoo/odoo#107800
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, following this flow:
- Add a form
- Add a selection field
- Add an option starting with a number
- Save
=> The created form's option value is only the number
From the website_form options, the options HTMLElement of a form field
are generated using the field's records ids for their html element value
attribute (see FormEditor._renderField).
When [1] refactored the website_form options to use a generic
ListUserValueWidget, the list records id computation changed to use
parseInt instead of strings.
This commit changes the detection of parsable int to match only strings
that are made only of digits, and less than 16 of them so that their
value is not lost.
[1]: https://github.com/odoo/odoo/commit/9304f8fa7bb94f21dd4caa83f9679ffd1642691b
opw-2980760
closesodoo/odoo#108248
X-original-commit: 166f4aa4d23a01901585b60d69fac47fe70b7ebe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
To Reproduce
============
- change language to Arabic Syria
- go to any form that has a Date field and try to change the date
the Date won't change
Problem
=======
the default numbering system of Arabic Syria is not defined so we take the default one
which is `latn`, when parsing dates using this numbering system we got a parsing error
because `latn` is not compatible with Arabic Date.
Solution
========
Numbers in Arabic Syria have the same format as the numbers in Arabic (Default one),
so we add Arabic Syria to the pattern.
opw-3081285
closesodoo/odoo#108247
X-original-commit: 8c50eb447da41a3ae0186d99972dd7e56d12cd23
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
As the previous commit explained, there is sometimes a gap between two
shapes due to some browser rounding errors, especially when using
browser zoom. However, there are also some things we can do in our
shapes themselves to decrease this problem.
This commit fixes two pairs of shapes which were easily fixed by
reviewing the rounding of one path and making the viewBox a square
(making a viewBox a square is known to solve issues). However:
- The first pair is not entirely fixed, the error is just reduced.
- The second pair is fixed... but the shapes actually do not join very
well (somehow the linear gradients do not seem to join properly)...
but still better than a white line between the two.
Reminder: several commits had attempted to fix this before ([1], [2],
[3], [4]) (and this commit's parent). But that wasn't enough to stop it
happening. Some shapes still need to be fixed although that will likely
be done in future versions.
[1]: https://github.com/odoo/odoo/commit/c0f62593a4da37e8404dddc0a5762879a5ebbf7f
[2]: https://github.com/odoo/odoo/commit/ac82407b259eab929486bf0a333a48bc507efa60
[3]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
[4]: https://github.com/odoo/odoo/commit/e386f318f5cff50901dba3db8a2587911ba02a6e
task-2824607
opw-3069213
opw-3057533
closesodoo/odoo#108228
X-original-commit: 52e5afaa10ca7f2b3183bf6359b42929a9b3704a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Aaron Bohy