With this commit we support adding FieldDependencies on custom widget, consider
FieldDependencies given on custom widget and add it to fieldInfo so that when
modal does calls to server to fetch data it consider those fields while reading
this will let us to design custom widget which may have some other fields in
dependency, say for example weekly recurrence widget which uses sun, mon etc.
fields, so with this we can fetch data of those dependent fields without adding
it to view.
task-2335399
closesodoo/odoo#60277
Related: odoo/upgrade#2021
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
with this commit we adding weekly recurrent widget, currently proeject and
calendar shows boolean for each day vertically but with this widget we displays
week days and its boolean horizontally.
Here widget will display first day as per language's week_start field, also we
adds FieldDependencies on custom widget and consider those FieldDependencies
while processing view node in basic_view.js
We add support of registry to contain owl custom widgets and add support
of rendering owl custom widgets.
Also with this commit we removes fields like sun, mon, tue etc. from view and
instead use "web_weekly_recurrence" custom widget to display boolean for each
week day.
Co-authored-by: Mohammed Shekha <msh@odoo.com>
add support of <widget> tag for owl, In order to prepare the future,
we want to convert everything in Owl, in future widgets generated by
<widget> tag will also be converted to owl.
with this commit we support widget to instantiate using ComponentWrapper.
task-2337692
Co-authored-by: Aaron Bohy <aab@odoo.com>
with this commit we changes field names for week days like su, mo, tu etc. to
sun, mon, tue and so on in calendar module, this is going to be used in
task 2317795 where we developed recurrency module for recurrency mixin.
Also with this commit we change field names of weekdays in lunch module to have
same name as we have in calendar and project module so that we can easily use
custom widget "web_weekly_recurrence" instead of defining boolean field in xml
for each day.
task-2335399
Co-authored-by: Mohammed Shekha <msh@odoo.com>
The confirmUpdate method in list_editable_renderer would destroy all
rows' widgets and recreate them *except* the currently modified one
(this one gets updated).
The problem was that the widgets of the current row were recreated
anyway. It created a memory leak.
This memory leak isn't such a big deal, as anything is garbage
collected as soon as the view is left anyway (so it's a small leak
during the lifetime of the x2many list)
The fix consists in keeping the reference of the widgets on the
currently modified row, and when all rows' widgets are recreated, we
delete a replace by our reference for the current row.
closesodoo/odoo#68386
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a list editable used as a one2many representation, inside the
confirmUpdate method, the on_attach_callback method on the field widgets
wasn't called.
It wasn't detected earlier because most of the legacy widgets didn't
implement this callback (all owl components do however).
It was problematic as the confirmUpdate function destroys and recreates
all the field widgets (with exception for the currently modified row).
Not calling the on_attach_callback would result in missing / unexpected
behavior such as _applyDecoration not being called.
The fix is simple: call the method if it exists on all the widgets after
they have been created.
*: web_editor
All theme specific color palettes have been moved into website.
It allows to access them without having to install theme modules and
this is a preparation for our website configuration screen task.
Lists of palettes have been replaced by maps with palette names as keys.
Those names are composed of the palette's original theme name ('generic'
or 'base' for palettes not specific to a theme) and of an index
(ex: 'anelusia-2'), for compatibility.
To keep compatibility with previous version we also convert old color
palettes number to color palette name, specifically for each theme.
A side effect of this change is that we got rid of all gray palettes
which existed in some themes. Those were not fitting the new possibility
of gray customization in the third panel and were not always really a
good customization of the default grays (they still were there mainly
for historical purposes). Unfortunately, this may have some side effect
for old websites which used those grays but the new gray palettes (left
to the default one) should most of the time come as an improvement of
the old ones, and they are now customizable by the user. In the future,
we may associate a perfectly-chosen default gray palette, fitting the
customization system, for each color palette.
PR: https://github.com/odoo/odoo/pull/67488
task-2451965
closesodoo/odoo#67488
Related: odoo/design-themes#455
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently, groupby and filter dropdown are not working properly
on employee kanban card because when dropdown is exact on position of
fixed-bottom it will direcly click on the kanban card instead of the
custom groupby dropdown due to higher z-index of the fixed-bottom then
dropdown-menu. also chat icon in fixed-bottom is overlap on zoomed
image as zoomodoo-flyout has z-index 100.
fixed-bottom has z-index 1030 while drodown has z-index 1000 so instead
of clicking on dropdown it was going to click on kanbancard bottom.
So in this commit, improve the behaviour and decrease the z-index of
fixed-bottom to allow the click on custom groupby dropdown and hide
the chat icon behind the zoomed image.
Also when try to create contract, employee field does not show proper.
so moved it before start date with label.
closesodoo/odoo#66788
Taskid: 2452363
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since AFIP requires to keep the original amounts in the txt files
for the digital VAT Book, we deprecate the option
'company_currency = True' in the methods used to prepare the data.
closesodoo/odoo#67927
Signed-off-by: Josse Colpaert <jco@openerp.com>
Purpose
======
Sometimes, a task can only be completed once another is (e.g. 'install boiler' can only be done once 'order boiler' is complete). Communicating this information is key to organize a project and for the users to know on what they can start working when.
## Settings in Project App
- Add a 'Task Dependencies' setting under the 'Tasks Management' section
- Add the same setting on the project form view.
- As for the sub-tasks feature, enabling this feature in the settings of the app, should enable it on all existing and newly created projects with is_fsm = false.
## Task form view
- Add a 'Blocked by' notebook.
- In this notebook:
- add new many2many field called *depend_on_ids* containing the tasks in which the current task depends on these tasks with the following fields displayed by default: name, user_id, date_deadline, stage_id.
- add a 'view task' button on each line that should open the corresponding form view.
- Filter task list for depend_on_ids Many2many field.
- Check no cyclic task dependencies.
task-2387984
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#66740
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Some documentation was removed to reduce technical debt + they deemed
were self-explainatory. The links to these pages are removed to match.
Some links were also updated/changed to redirect => these links have
been updated to match the new addresses.
closesodoo/odoo#68214
Task: 2457087
X-original-commit: 49cfc4165ff19f6fd293bed2f6867a32cc0b8c5d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps:
- Install Sales
- Go to Settings / Translations / Languages
- Install Dutch
- Go to Settings / Users & Companies / Users
- Change demo's language to Dutch
- Go to Sales / Configuration / Settings
- Activate Coupons & Promotions
- Go to Sales / Products / Coupon Programs
- Create a new Coupon Program
- Click Generate Coupon
- Generation Type: Number of Selected Customers
- Matching rule: Name contains demo
- Generate
- Go to Settings / Technical / Email / Emails
- Open the email you just sent
Bug:
Parts of the email are not translated
Explanation:
The `lang` field is used to determine the template's language. Coupon
emails where missing one.
Also, the subject of the email wasn't translated.
opw:2467640
closesodoo/odoo#68366
X-original-commit: cb57e5dd9d850820f715b5ce4048c81f96b028b1
Signed-off-by: backspac <backspac@users.noreply.github.com>
Because kits might never be in stock, it's impossible to fullfil the
quantity of a reordering rule: asking a mini/maxi quantity on a kit
makes no sense.
Odoo will continuously propose to order more to reach the quantity
necessary for the kit, but will never reach the asked qty, as it's a
kit, not a manufactured product.
OPW-2448878
closesodoo/odoo#68362
X-original-commit: c47a9319c081105e46e56f881b25fd6442266089
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
- Install contacts & point_of_sale
- Go to Contacts and import a contact from an Excel file with the following data:
/!\ The street field should contain a line break /!\
Name | Phone | Street
-------------------------
Test | 123456 | Multiline
Street
- Open a POS session
- Go to Customer selection page
- Search for "123456"
The imported res.partner will not be found by his phone.
A partner search in POS is working with a regex search on a string containing all partners.
This string is supposed to contain 1 line for each partner and a line is formatted as followed:
id:name|barcode|address|phone|mobile|email|vat
However, in this case, partner's address contains a line break, resulting on a line like this:
id:name|barcode|address (part before line break)
address (part after line break)|phone|mobile|email|vat
This partner is defined in 2 lines and all data from the second line cannot be matched with regex.
opw-2477994
closesodoo/odoo#68365
X-original-commit: 3de16a7a4616c73cfabd64aa010801f687cf14af
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Before this commit, Creating new `Deposit Product` from Settings was not setting type to `Service` while we have the domain to display on Service products here.
Now, we added the Default type in context.
closesodoo/odoo#68364
X-original-commit: 7e8019be992a7919ca94ad7cf6c1e83156812b1c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit displaying a map on the website required the use of
the Google Maps snippet which requires to configure an API key.
After this commit displaying a map on the website can also be done with
a simpler Maps snippet which requires no configuration.
task-2464422
closesodoo/odoo#66766
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose of the commit is to display the default label next to the icon
for state_selection widget in list view.
also that widget support the hide_label option to hide the label in
state_selection widget of the list view.
Related Ent PR: odoo/enterprise#16559closesodoo/odoo#66589
Taskid: 2451287
Related: odoo/upgrade#2195
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the commit is to do the generic improvement for the
refactoring of project.
So in this commit, done the following changes:
- move the date_deadline and the tag_ids field to the right column
- remove the warning 'by saving this change, the customer email and phone
number will also be updated.'
- track the priority field on task
- move the deadline field above the fa-star and fa-clock-o icons
- the name of archived tasks should be crossed out
- project form add a 'deadline' field below the user_id one
- project form remove the 'description' notebook
- remove the 'project' field from the quickcreate of task.
Related Ent PR: odoo/enterprise#16559
TaskID: 2451287
Purpose
======
Currently, the user can configure his field service project to be billed at an employee rate but it just won't work. The rates configured for each employee on the project are not taken into account when the task is marked as done. As a consequence, the only workaround to support this kind of use-case is to create 1 task per employee with a different rate (or to add service products on the task). Those solutions are far from being ideal. We should give more flexibility.
## Details
To reach the goal, some updates are made:
- Move the timesheet_product field in employee mappings into the fsm sale module, because this field is only used for fsm projects,
- render _timesheet_determine_sale_line no static to easily override it,
- fix bug when the user change project on task form view, the project for non billed timesheets is not correctly changed,
- let the SOL in task when the user wants to change the project of it to a project with pricing type defined as employee rate. Before when the pricing type of the destination project is employee rate, we remove the SOL of the task.
task-2376382
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#66157
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the task is to update all l10n modules icon with new icon that i have
found in task attachment.
So in this commit, Updated all l10n modules icon with new icon.
closesodoo/odoo#65329
Taskid: 2442631
Related: odoo/enterprise#16054
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
changed the start/end date fields to datetime fields, in order to allow more
flexibility for the user and enable them to set a precise point in time at
which ticket sales should start/end, because otherwise ticket sales/end would
always be set at midnight which is not very flexible.
Task-2431440
closesodoo/odoo#65133
Related: odoo/upgrade#2126
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of the task is, 'general setting' is not easily understandable
by the user. The user often gets lost. This is especially damaging
through onboarding as some new users like to discover the software by
scrolling through the general settings.
So in this commit, the general setting is well organized and easily
understandable by the user.
Related PR: https://github.com/odoo/enterprise/pull/14707closesodoo/odoo#61645
Taskid: 2374990
Related: odoo/enterprise#14707
Related: odoo/upgrade#1958
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when the user adds a line in the employee mappings
from the project form view, the new line appears at the top of the list.
This commit changes to display this new line at the bottom of the list.
task-2376382
closes#66157
Before this commit, when many sales order items have a same product with
a different price_unit, the user cannot know which one of these sales
order items has the product with the expensive price with just the
name_get of the SOL in task form view.
This commit adds the price_unit in the name_get of the sale order items
only for the sales order items in a same sales order have the same
product.
task-2376382
closes#66157
Before this commit, the label for timesheet_product_id field in the
project form view was "Service". Now with this commit, this label is
equal to "Default Service".
task-2376382
closes#66157
Before this commit, when the user changes the project on the task to
choose a project with the pricing type to employee rate, then the SOL on
this task is removed.
This commit removes this behaviour to let the SOL of the task.
task-2376382
closesodoo/odoo#66157
Before this commit, when the user changes the project_id of a task, all
timesheets from this task have not the new project, because only the
timesheets not invoiced and the ones with no SOL or with the same SOL
than the task are updated.
The problem is the not invoiced timesheets with another SOL than the one
in the task keep the old project.
This commit changes the condition to change the project for the
timesheets are not invoiced.
task-2376382
closesodoo/odoo#66157
Before this commit, this method is static to the model. But in fact, we
always use the project, employee and the task from the current
timesheet. So it can be better to directly have this information in the
self.
This commit changes this method to have no params into it and only use
the self to retrieve the useful data.
task-2376382
closesodoo/odoo#66157
Before this commit, the timesheet_product_id field in
project.sale.line.employee.map model is defined but never used.
This commit moves the definition of this field in the industry_fsm_sale
module to use this field in that module.
task-2376382
closesodoo/odoo#66157
Before this, due to the order the lines were interated on (their sequence), some lines were duplicated without parent, making the duplicate report's layout different from its parent. We now ensure we treat the lines in an order that guarantees the parent line has always been copied before its children.
closesodoo/odoo#68011
X-original-commit: c815342b986851e0a4733ed5bf9fbcc7f8fb7442
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit it was rather painful/cluncky to find a way to remove this block.
By setting a name on the block we can easily xpath it to replace it or add extra content within.
This makes it easier for external devs to influence this view.
closesodoo/odoo#68010
X-original-commit: d418e4e16a46a0d499e606598b3524eabd19e5fd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The current behavior was to set the label as memo in the payment register wizard.
However, this is to restrictive when a vendor bill hasn't any payment reference but a bill reference.
In that case, the user is expecting to have the bill 'ref' in the payment 'memo'.
Since the matching rules in the reconciliation widget are matching line.name, then line.move_id.ref and then line.move_id.name, the same logic is applied here to construct the payment 'memo'.
closesodoo/odoo#68004
Opw: 2440389
X-original-commit: 92ceb86d58f4d78c8a4256f29d101d3730517b93
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The Lunch module can automatically send an email to a supplier with the
daily orders at a configured time. It can also remind the users via chat
so they don't forget to order their sanddwish.
Before, two high frequency cron jobs were responsible to check every 20
and 5 minutes if we reached the moment when to send the email to the
suppliers or the notification to the users. Together the two crons were
executed 360 times a day.
The new model uses a dedicated daily cron per supplier record and per
alert record, the dedicated cron is created on the fly and its moment of
execution automatically updated to reflect the supplier/alert record.
See also #41858 for prior work.
closesodoo/odoo#63749
Task: 2416741
Related: odoo/upgrade#2044
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
It shouldn't be possible to create refunds on misc journals, as the tax report would compute the wrong multiplicator sign, and hence end up being entirely wrong.
Introducing the constraint also allowed finding an issue within _move_autocomplete_invoice_lines_create: some tests directly create an invoice by giving it line_ids instead of using the invoice_line_ids helper. The former implementation of this function made it so that the default type wasn't set in the context properly, and these tests were putting their invoices on misc journals. We fix this here as well.
closesodoo/odoo#67965
X-original-commit: fdc96de0e411760f84a78c36543f9157332346de
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue
- Install 'Blogs' module
- Create a blog post
- Set published_date to 01/01/1997
- Go to website
- Edit any page and add a 'Blog Posts' Block
- Set 'Layout' to 'Cards' (or 'Horizontal')
- Save
In snippet cards, the blog post date is not the published date.
Cause
Displaying update date ('write_date' field) instead of
the published date ('post_date' field).
Solution
Replace 'write_date' by 'post_date'.
opw-2443104
closesodoo/odoo#67985
X-original-commit: 681e709b239c2456c71d1c16bb40de055dfb927c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Client issue: when updating the company of a contact, the Display Name
keeps using the previous company's name, so given Bob in company A, if
Bob is moved to company B the form's title remains "A, Bob" instead of
becoming "B, Bob". More annoying, if Bob is moved back to A the name
becomes "B, Bob".
On res.partner, `display_name` is a stored computed field which
depends on `commercial_company_name` (via `name_get` -> `_get_name` ->
`_get_contact_name`). This is an other stored computed name, which
depends on `commercial_partner_id`, which is yet another stored
computed name, which depends on the `parent_id`.
The dependencies are meh but usually resolve fine, the issue occurs
when a base.automation rule is created with a non-empty
domain (including an empty literal list, which was the case here):
when the first field of the sequence is computed, base.automation's
`_compute_field_value` is called. This calls `_filter_pre`,
which (because `filter_pre_domain` is non-empty) calls `search` on the
model.
This would normally be innocuous as `search` will only flush the
fields used in the search, however for `res.partner` the default
`_order` is... `display_name`. Meaning we flush that computation,
forcing the computation of `commercial_company_name`, but since
`commercial_partner_id` is being computed we reuse its old value (or
something), which is not re-recomputed after the
`commercial_partner_id` computation ends.
So rather than resolve a full search involving an order, filter the
records in-place.
OPW-2427264
closesodoo/odoo#67987
X-original-commit: 221ea6079b2beeb66c4cfa48b237791e1b380c5e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
To find the main element which scrolls in the page, we rely on its
height being as tall as the body one. The code which checks that was
making a comparison between a rounded value and floating value without
care of the rounding errors that might induce, especially on zoomed
pages.
Fixes https://github.com/odoo/odoo/issues/63306closesodoo/odoo#67986
X-original-commit: 71b6fc7341dfec5e8fc2352c3143b1e324a880f8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Sales"
- Switch to "German" language
- Go to Sales -> Products -> Products
- Try to filter on "Public Price" is equal to "2,3"
Not possible to add decimal point at the end (only in middle of number).
Cause
In case the 'decimal point' in DB params is not a dot '.',
the filter input will be considered as 'text' instead of
'number'.
In case of the 'number' type; HTML do already a pre and post
processing, including managing decimal point (who, for example,
is not included in ev.target.value if last char is a '.').
Unfortunalty, the library is not well working with other
language and not supported on every browser, therefore,
must use own logic.
In case of a 'text' type, the value will be send to 'parseFloat'
,then `parseNumber` will replace decimal_point by dot (also one the
issues since needed to display decimal_point according user language),
and `Number` will remove the decimal_point in case of '123,' -> '123',
and therefore we will not be able to write decimals ( apart of adding
the decimal point after writing the whole number...)
Solution
If user input is well parsed, store parsed value in condition.value and
set condition.displayedValue to the input value (an so without updating
input value). Else, replace input value with previous value (who should
be the condition.DisplayedValue).
opw-2463441
closesodoo/odoo#67978
X-original-commit: e795ce5bff14b6b748c1f4a2651946aafdc299f4
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When adding a variant product, if the option "Variant Grid Entry" is
enabled, it will reset the delivery date of each purchase order line.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Variant Grid Entry"
2. Create an RfQ
3. Add the field "Delivery Date" to purchase order line view
4. Add a basic product (e.g. "[FURN_6666] Acoustic Bloc Screens")
- Keep its delivery date in mind
5. Add a variant product (e.g. "[E-COM12] Conference Chair (CONFIG)")
Error: The delivery date of the first purchase order line has changed
for no reason. Moreover, suppose that in step 4, the user defines a
specific date: the latter will still be changed after the variant
product is added.
When adding a product, the delivery date of the purchase order and its
lines are recomputed. However, an override of `onchange` ensures that
the new delivery date of the lines will be ignored if the `onchange`
concerns the field `order_line`. Here is the problem: when using the
Variant Grid Entry, the `onchange` concerns the field `grid`. As a
result, the new delivery dates are kept. This explains the creation of
`_must_delete_date_planned` in this fix.
However, when returing the result of an `onchange` linked to `grid`, the
result contains the existing lines (on client side) and the new ones
(from the Variant Grid Entry). If the field `date_planned` of the new
lines is deleted, the client will raise an error when it tries to render
these dates (it has no information about their value). Since existing
lines are of the form `(0, <client_id>, <values>)`, this fix only
deletes `date_planned` field for lines with <client_id> defined.
OPW-2454164
closesodoo/odoo#67972
X-original-commit: d2d495bca3e91862470702f1ef07aa27c33d8e2d
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Allow creating a journal entry in the past after having changed the
sequence number reset on newer sequences.
opw-2445559
closesodoo/odoo#67963
X-original-commit: 26a43f23ec2b2490aec0731e25568703729581f0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, we create a container to add the new options in the
project settings.
This commit removes the container to put these options in the default
container.
task-2387984
closes#66740
Before this commit, if we have for instance 3 tasks called A, B and C
where A depends on B and B depends on A then we have a cyclic dependency.
Another example with the same tasks, we can have a cyclic dependency if
A depends on B, B depends on C and C depends on A.
This commit checks we have no cyclic dependencies when the user adds a
dependency on a task.
task-2387984
closes#66740
