On the purchase dashboard(s) the context would never be passed on the
rpc calls that load the upper panel, which caused the result to always
be as seen from the default company.
Closesodoo/odoo#74882
Task ID: 2610547
Related: odoo/enterprise#20145
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to display the value of
timesheet_min_duration and timesheet_rounding fields
center in the setting of the timesheet app.
So, In this commit add a text-center class for that fields in
XML of the setting in the timesheet app.
closesodoo/odoo#74849
Taskid: 2616165
Related: odoo/enterprise#20135
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously if one of the text in the project's kanban view's setting
pane was too long, the setting pane would overflow and display a
horizontal scrollbar in order to fit everything.
Closes: odoo/odoo#74822
Task ID: 2618321
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously the settings pane toggle (on the project's kanban view) would
disappear when the cursor would not be hovering the kanban record.
Closes: odoo/odoo#74822
Task ID: 2618321
Tasks that are blocked by other tasks don't get any other information
from those tasks.
In order to get updates on the state of the blocking tasks we now track
some fields (determined by the `task_dependency_tracking` attribute) in
the parent's chatter.
Task ID: 2601448
closesodoo/odoo#73965
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps:
1. Create new time off allocation
2. Set type to accrual and set start date other than present day
3. Set the accrual to add every month
4. Validate and run the scheduled action for Accrual Time Off
5. Check the field 'nextcall' with Studio or editing form view
Result:
Nextcall date is set to 1 month after the date of creation of allocation record instead of start date.
Solution:
Nextcall is now based on start date.
opw-2558480
closesodoo/odoo#75234
X-original-commit: 3f7f0feb31d80c5cb3364c3a7d530c80b6278b40
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: Audric Onockx <auon-odoo@users.noreply.github.com>
*: hr_holidays, im_livechat, sms, snailmail, website_slides
Most messaging related components have common needs concerning
subscribing to model changes, and not needing to be rerendered unless
their props change. Previously, most components would call the hooks
"useModels" and "useShouldUpdateBasedOnProps" individually. Messaging
components also depend on one another quite a bit, requiring a lot of
explicit imports of other components. It would also be useful to be able
to have cyclic dependencies between component (eg Message renders a
component that allows to delete the message, and the delete component
renders the message in a confirmation dialog), but that doesn't work
with explicit imports (the odoo module system doesn't support cyclic
dependencies).
This commit adds a Component decorator that:
- Registers the component in an internal registry
- Makes all components in this registry available at render time to
components that have been registered in this way
- Calls the useModels and useShouldUpdateBasedOnProps hooks during
component initialization (setup)
enterprise PR: odoo/enterprise#20304closesodoo/odoo#74982
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
We need quantity in tax line and we added from this PR https://github.com/odoo/odoo/pull/73402
but after it creates a problem in tax amount
because in tax line, the unit price is set base on quantity and by default is 1 but after PR 73402 it's the same as invoice line so rounding issue is there and this rounded amount is multiplay by quantity so this creates a big difference
before PR 73402:
Name | unit price | quantity | taxable amount |
=====================================================
Product A | 5.55 | 8000 | 44400 | (invoice line)
Tax 5.0% | 1 | 8000 | 2220 |
```
After PR 73402:
Name | unit price | quantity | taxable amount |
=====================================================
Product A | 5.55 | 8000 | 44400 | (invoice line)
Tax 5.0% | 0.27 | 8000 | 2160 |
So in this PR we remove quantity from grouping key
closesodoo/odoo#74818
X-original-commit: aa160f4c0a04500bd91eea8da2cec165a15270a6
Signed-off-by: Josse Colpaert <jco@openerp.com>
Steps to reproduce the problem:
- Connect as admin
- Create a new employee, e.g: “Employee1” for company “My Company (San Francisco)”
- Create a new time off request for this employee, and select a time off type linked to the company "San Francisco"
- create a user and do not give him access to the company “San Francisco”, e.g: “user1”
- Log in as “user1”
- Go to time off > Managers > Allocations > remove default filter
Problem:
user1 is able to see the time off allocation of “Employee1”, even though he does not have access to My Company San Francisco.
Solution:
Add multi-company rules for the “hr.leave_allocation” model to display only the time off allocations to which the current user has access
A rule has already been added for "hr.leave" model:
https://github.com/odoo/odoo/blob/0f3281e3b1dc943b81d79d2a8f82fca7b95b8186/addons/hr_holidays/security/hr_holidays_security.xml#L65-L70
opw-2535709
closesodoo/odoo#75220
X-original-commit: a6f951845d5de869b2e138403aecfd4c653bf8b3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Steps to reproduce the bug:
Go to your computer's date settings
Change region, e.g: (US or choose a region with a negative UTC)
Go to the preferences settings in odoo > Change the timezone to US too
Go to Time Off app > Manager > Allocations > Create a new one
Allocation type : "Accrual Allocation"
Set the end date to, e.g: "04/07/2021"
save
Problem:
The end date moves back by one day.
The field " date_to " is of ”datetime” type, so we use in the view "widget="date"
Therefore, the user can only choose the date. We save the time in the database at" 00: 00:00 ".
But as we use in the view "widget="date", after saving the record,
the datetime will be converted to a date, based on the user's UTC.
For example, in our case:
in database, date_to = "2021-07-04 00:00:00"
user UTC = "UTC-6"
result = "2021-07-04 00:00:00" - 06:00:00 → "2021-07-03 00:18:00"
Solution:
Remove the widget date to allow a user entering the full date (eg: 2021-07-04 23:00:00), that
will be stored correctly in UTC afterwards, instead of having the widget making the date switch to
another day.
opw-2607082
closesodoo/odoo#75218
X-original-commit: 2ddabf087004e14ac77aa397eb345d750026dd20
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
PURPOSE
Fix issues generated due to conversion of text field into Html field.
SPECIFICATIONS
Improve integration of HTML fields as well as "empty html" management.
See various commits for more details.
Followup of odoo/odoo@cb4f597 and odoo/enterprise@971f3ed
Task-2558824
closesodoo/odoo#74795
Related: odoo/enterprise#20117
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before commit[1] there was only one field image_1920 in group with 'colspan=1'.
In commit[1] a new invisible field avatar_128 is added in this group. But due
to this an empty 'tr' element is added in view and it breaks the view.
With this commit we move avatar_128 field outside of the group and placed it
with other invisible fields, so it doesn't break view. And also adding comment
field in new group because it is html field now so it displays nicely.
Followup of odoo/odoo@cb4f597410 and odoo/enterprise@971f3ed9ae
commit[1]: c53724ebc3
LINKS
Task Id-2558824
PR odoo/odoo#74795
PR odoo/enterprise#2011
Followup of odoo/odoo@cb4f597410 and odoo/enterprise@971f3ed9ae
We have converted string into markup string in repair as we cannot concatenate
strings directly to Markup string. And if we try to do it we will see the
html elements '<br/>' in field value, so we have to convert '<br/>' string
into markup language to avoid this.
Also avoid adding pseudo-void html content in narration.
LINKS
Task Id-2558824
PR odoo/odoo#74795
PR odoo/enterprise#20117
New reception report added for non-outgoing transfers. This is intended
to support easier stock allocations by allowing dynamic MTO
assignment/unassignment, e.g. if we have an incoming transfer with
products we want to assign to an existing outgoing transfer, then we can
use the report to create a MTO link to the specific outgoing moves. To
support this assignment flow, the report also allows printing of labels
to place on the product so stock workers know which transfer/MO the
product has been assigned to.
Expected use case is when a product is purchased to fulfil a sale.
Demo data has been added so reception report can be immediately
seen/used for this flow.
Implementation Notes:
- Report has been made flexible to work with batch transfers.
- Only done moves can be assigned to moves that already have quants
reserved (prevents undesired behavior + this makes sense logically)
- Confirmed (+ Done and everything inbetween) moves can be assigned to
any confirmed moves that are not already assigned.
- Report does not affect quant reservation/unreservation at all. It
works only with linking moves (i.e. move_orig_id/move_dest_id) so
move/transfer linkage traceability is stored within db (i.e. this
isn't possible with quants)
Limitations: To keep code simple for now, this assignment flow will
break in certain cases:
1. Done amount of an assigned move is less than the Demand amount
(linked move will not autoreserve correctly when assigned move is
validated, same issue already occurs in multi-step transfer).
2. If a linked move is unreserved after its assigned move is
validated, then another move can reserve its quants and its
assignment link will not be accurate.
3. Already reserved SNs + assign move, may lead to mismatching SNs
between report and what's actually reserved.
4. Changing a linked move's Demand amount after a move is assigned to
it.
5. Potential moves to assign to are only checked for being in same
warehouse, not in a matching source location to destination location.
User is expected to make this match on their own.
Task: 2500844
ENT PR: odoo/enterprise#18268
Upgrade PR: odoo/upgrade#2731closesodoo/odoo#70669
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In 14.0, when adding a form to a website and selecting "Create a Task" without
an active project, an error pops up because no projects are found.
In this commit, we prevent an error from popping up when adding the form
without projects, by allowing the field to be empty (not required).
task-2580436
closesodoo/odoo#75221
X-original-commit: a5d8648531f9a0e9616f23b66c67ff32fdb0f0ea
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
When clicking on the 'New quotation' action,
if no current customer is linked to the lead,
a popup opens with the following options:
- Create a new customer
- Link to an existing customer
- Do not link to a customer
If odoo found a potential matching customer but we decide it is the
wrong one and select the first option, a new one should always be
created
opw-2545065
Task-2622793
closesodoo/odoo#75213
X-original-commit: 728f8611caa8fe3f3bdc88a9650f7edb05321a87
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue: When closing a PoS session, the user can Cash In/Out of the
register but it requires Accounting/Billing group or Purchase/User
group. However with Purchase/User group, there was an access right
error (not allowed to create account.move.line
Steps to reproduce :
1) Install PoS Module
2) PoS > Your Shop > Settings and enable Advanced Cash Control
3) As administrator and in debug mode go to
Settings > Users & Companies > Users
4) Remove Accounting, Inventory and Purchase group of [User A]
5) Log in with [User A], open a PoS Session, close it, and in Cash
Control form, click Cash In/Out
6) Remove or add money
-> Access right error, you need to be Accounting/Billing or
Purchase/User
7) As administrator, add the User group to Purchase for [User A]
8) As [User A], click Cash In/Out, removed or add money
-> Still access right error
Why is that a bug:
The first warning asks us to give the Purchase/User group to the user
if we want to Cash In/Out but even when doing that, the access rights
are still not enough to allow the creation of the entry
opw-2611298
closesodoo/odoo#75156
X-original-commit: a28c9c1dd773f26151d6734d476e7f8d5a3d971b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
All background-color classes (bg-XXX) were defined before the color
combination classes. Except for the Odoo colors ones (bg-o-color-X)
which were defined after. That inconsistency was not a real problem
before as those two type of classes could not be combined but this will
change in the future.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
Currently, track proposals are submitted through an HTML form with an "action"
attribute, which requires that the associated route returns a redirect
response.
However, redirecting to a different page comes with its set of issues.
Indeed, when the track is submitted, the user that just submitted the track no
longer has access to it (because it's not published).
In 157a1d77058da97954edc9efba6ab9f43c7d13a2
We attempted to resolve this issue by checking if the partner set on the track
is the same as the partner set on the website.visitor record.
However, this does not handle every use cases since when specifying different
contact information, we create a different res.partner, making the check fail.
In this commit, we rework the track proposal submission to use AJAX instead.
This allows to dynamically show a "success" message while staying on the same
page, removing the need for redirects and "complex" ACLs checks.
While the main goal of this change is to avoid the need for that security
check, it also has a few additional minor advantages:
- Slightly faster UI, as you don't have to wait for a full page reload
- Fewer routes to maintain
- Easier and more thorough validation handling (current code returns a ugly
error page if validation fails server-side)
- Code makes a bit more sense, as we don't have a template that varies from
"form" to "success message" depending on the presence of a "track" variable
Task-2618734
UPG PR odoo/upgrade#2722closesodoo/odoo#74848
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does not change anything, it simply applies linting on the track
proposal JS files to match our current guidelines.
This is done as preliminary work since we are going to change the way track
proposals are submitted (from POST request to ajax POST).
Task-2618734
The editor sometimes compare CSS values, in particular in the
selectStyle method where a given style is not applied if it would have
no effect (e.g. applying an inline pink background-color is useless if
the block is naturally pink because of CSS rules). That comparison
failed when it was comparing 'var(--XXX)' and 'YYY' as 'var(--XXX)' was
not processed as the CSS variable 'XXX' to be read.
Related to task-2599770
closesodoo/odoo#75201
X-original-commit: 22b5d90539895bb7c2b14de4abbb2d7d978a6f79
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The video linked to the "How to create your own piece of furniture" slide has
been removed from YouTube.
This commit simply updates the demo data with a new video.
Task-2621278
closesodoo/odoo#74899
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since 369075f
The slide.slide embed_code field is a HTML field.
Meaning that when it's used in a HTML block to embed content, it needs to be
correctly t-outed, the current t-esc code will just print HTML.
Task-2621278
In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:
- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)
This was solved in pdf.js whith this commit:
https://github.com/mozilla/pdf.js/commit/8805614a03
And this PR is backporting that commit in 12.0 version up to master.
opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311
closes#75020closesodoo/odoo#75057
X-original-commit: d3feb26c8923cfde60894058f06dc2c2a8be05f5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit fixes the display of the status bubble inside of the status
button on the project form view. It wasn't visible since the recent css
changes.
Closes: odoo/odoo#74610
Task ID: 2615293
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previous implementation always updated *current website*, which is not
always the same as the value from `res.config.settings`.
---
opw-2623007
X-original-commit: d66d44db031be76403ce7c01616e334ef196fd03
In a multi-company environment, with l10n_es_reports installed,
a tab was added to the invoice form view.
That tab was also visible in other localizations as well,
which was not desired.
closesodoo/odoo#74701
Task: 2611256
Related: odoo/enterprise#20042
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, Scrap move was copied to new record on
duplicating Scrap order.
With this commit, Scrap move is not copied.
closesodoo/odoo#75180
X-original-commit: a725fed5168a140cb631732c3ffc994cd90b02b2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
- create a sale order with an event registration,
- on the event, the number of attendees is well computed
- cancel the sale order
- on the event, the number of attendees is still the same as before
Cause of the issue
There was no specific action for canceling a sale order linked
to an event registration
Solution
Add a action_cancel method which cancel also the sale order lines when
canceling the sale order
Also add a test to ensure the flow will not break in the future
opw-2576790
closesodoo/odoo#75174
X-original-commit: 9dcfae2234b1f45da1837c519b54926522cfa070
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
EHF3 is the Norvegian standard for Peppol. This module generates xml (based on BIS3 with NO country profile) to be submitted on the Peppol network.
TASK ID: 2528203
closesodoo/odoo#70679
Related: odoo/enterprise#20050
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Overriding '_is_embedding_to_invoice_pdf_needed' is unnecessary since the default value is already 'False'.
- When calling '_check_move_configuration', we should not ignore the errors returned by 'super'
the deleted commit is not needed since it's already called in
`_procure_orderpoint_confirm`.
The logs are usefull to check whether we have progress on repeating the
scheduler that gives timeout error.
closesodoo/odoo#75146
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
How to reproduce the problem:
- Install the sale_coupon module
- Sales -> Products -> Promotion Programs
- Create a promotion with "Fixed Amount" discount, "Apply on current
order", with Based on Products as "Name = Large Cabinet"
- Create a SO with 3 Large Cabinet.
- Modify the quantity on the new reward line: the price unit became 0.
A client should be able to manually change the discount quantity.
That was not possible before due to the fact that the reward products of
a promotion are saved in the DB with a list price of 0.
As the reward generation handles the job of computing the correct
unit price on a reward SOL, that unit price is simply re-used when
the quantity is changed.
Also corrects the case where a Free Product is different from the
Rule Product(s): with the promotion
"Buy 1 Product A, get 1 free Product B", if the Sale Order has
3 Product A, for example, the promotion will offer only 1 Product B,
while it should offer 3.
opw-2522604
closesodoo/odoo#75143
X-original-commit: 97b78e8982f1e143350521bdee3c280618fb1846
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: prro-odoo <proose@users.noreply.github.com>
We introduce here an incomplete implementation of the new ControlPanel.
The idea is to allow the rewritting of the client actions that do not
use the search view but only the breadcrumbs or the button zone...
The full implementation of the new ControlPanel will be merged when the
new search infrastructure is ready to be merged.
closesodoo/odoo#75083
Related: odoo/enterprise#20231
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- fields/format.js has been renamed into fields/formatters.js
- fields/parsers.js has been introduced
- parsers and formatters from l10n/numbers have been moved to
fields/parsers.js and fields/formatters.js
- same for parseCurrency and formatCurrency, and they have been
renamed into parse/formatMonetary
- humanReadable option is now a boolean, no longer a function
- formatPercentage implementation has been simplified thanks to
that reorganization
- tests have been reorganized accordingly
Reintroduces a registry "formatters" that contains util functions for
formatting field values. Those formatters take the same parameters:
value, field, options.
William Braeckman