This commit: https://github.com/odoo/odoo/commit/0eba50dd1c33a08f8862a5718149e61b822e1b5a
introduced a 'return' in the survey.js script: return load_chart(chartConfig, '#scoring_results_chart');
This makes the rest of the script completely skipped and bypasses all the filter features.
task-2116078
closesodoo/odoo#39898
X-original-commit: b7baaf4846ba9208aeba8ba4db7de4f142e147cc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Fix a bug where you get a traceback when trying to join a course on a quiz
preview not in fullscreen mode.
A variable was badly named in JS (id -> channelId), leading to the ID not
being forwarded to the "Join Course" sub-widget.
LINKS
Task ID 2079476
PR #38051closesodoo/odoo#39891
X-original-commit: b32d30b8cde85ba37f9cef975838874a08ea7c07
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a pos order is sent to the server, the field 'to_invoice' is never
sent to the server which lead to always having a value to 'false'.
We are now sending correctly this value to the server, and we can also
base the fact to create an invoice on the value of each order.
Because beeing offline could lead to create an order that should be
invoiced as one that should not be.
closesodoo/odoo#39880
X-original-commit: c8d5b4a0cfc070c05c3f86ae6cc2b7395532c353
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Let's assume the following order of bank statement:
1 - 2 - 3 - 4
and now we change the date of statement 2 to be at the end
1 - 3 - 4 - 2
Changing the date triggers the recompute on record 2, that will correctly change it's
previous_statement_id to 4, however we also have to change to value of record 3 so that
it points towards record 1. This was previously done inside the recompute function by use
of a simple search and an assignation on record 3. However this caused some random issues
as if we try to access the record 3 value just after having change record 2 value, the ORM
might not have yet call the method to recompute record 2 (this is called when we try to
access record 2 value but we didn't do it in this case). Therefore the value in record 3
might not have changed yet. Hence the error spotted. The reason why this error only
happen some of the time is probably due to some method inside the ORM where we read the value
on record and those value are in a set meaning that it is not ordered and sometimes when
we were lucky the recompute happened before we tried to read the value of the other record.
The solution to this problem is to move the logic of other statements to recompute (in the
example record 3) inside the create/write method. And instead of assigning the value directly
only mark those record as needing to be recompute. That way whenever we try to access the value
of such record (record 3 in this case), if it was not yet recomputed, it will be done at that time
closesodoo/odoo#39867
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Before this commit, the user could not edit the lead phone field
when a customer was assigned. The phone field was related to the
phone of that customer.
Now, the field related to the phone of the customer is removed.
We can edit the phone field of the lead without modifying the customer
one.
task-2083470
closesodoo/odoo#38350
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
If a user levels up after passing a quiz, we want to clearly show him in the success modal that he
actually passed a level instead of just showing his new rank and xp gauge.
This commit introduces an animation with the progress bar when the user is levelling up.
After reaching the upper bound of the next level:
- The progress bar goes back to 0 ;
- The lower/upper bounds change to reflect the new reached level bounds ;
- The message "Amazing!" becomes "Level Up!" ;
- The motivational phrase changes with a fade out/fade in animation.
LINKS
PR : #39870
Task ID : 2032649
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This commit adds a SQL constraint to force the min_karma of the gamification.karma.rank model to be
above 0.
A karma_min set to 0 (or lower) could create some frontend issues when displaying required karma.
PR #39870
Task#2032649
The return type of the _get_next_rank method on the 'res.users' model was inconsistent.
It sometimes returned a recordset, sometimes False.
This commit adapts the method to always return a recordset (which is empty for the previously
'False' case).
This is a preliminary work for the level up animation on website_slides task.
PR #39870
Task#2032649
The commit 748f0c88c5 changed the "completion" field from a number of
completed slides to a percentage of completion.
The computation used in the user profile has to be adapted accordingly.
PR #39870
Task#2032649
The commit 3c4bb08 fixed an issue about reservation from transit location
for versions from 11.0 to 12.0 by soften the record rule on stock.move
From 12.3, we need to additionnaly soften the stock.move.line rule
to have the same result as this model has a record rule too since that version
closesodoo/odoo#39859
X-original-commit: b8b63d387b5af5928001ca7a53ef66916bc070b9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Create a customer without email address, go on the accounting module
create an invoice for this customer.
Go back to the invoices list and select some of them including your
invoice for your customer without email address. Send them by mail.
You will have a traceback and the wizard will be broken.
This bug is caused by a change in the account module, there is no more
reference, they are replaced by the name of the invoice.
OPW-2085837
closesodoo/odoo#39856
X-original-commit: d1feb088228e1fe74c917ecdd5f4c0e87d253263
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- In the sales or accounting module, create some invoices.
- Select them then click on `action > send & print`
- The wizard opens but not in the mass mail mode.
It creates some inconsistency and if you click on send,
the invoices are sent to the wrong customer.
Sometimes, the invoices are not sent at all.
I think the problem comes from the `_compute_composition_mode` method
who set the value of `composition_mode` on the wizard instead of
on the composer.
OPW-2085837
X-original-commit: 2496125f29cf1bd5b7a37384897f49bed86e69d8
Indeed, the carousel-item elements are linked to other DOM (like
indicators) and removing one would imply enabling another one... all of
this is handled by the carousel "remove slide" option.
Note: the UI to add and remove slides will be refactored in a future
update of this future saas anyway.
Part of https://github.com/odoo/odoo/pull/38997
task-2090180
closesodoo/odoo#38997
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when an user clicked on a control button to go to
another carousel slide, the overlay ended at the wrong position and
multiple scrollbars appeared. This occured because bootstrap fires the
'slid.bs.carousel' event too soon, because it emulates the transition
end event with a setTimeout. So on a normal computer, this occured:
- User click on control button, transition starts.
- slid.bs.carousel is fired -> we retarget the edition to the new active
slide and reposition the overlay... but that slide is still moving
as the transition is not really finished.
- The transition finishes, the overlay is at the wrong position, outside
of the screen.
Actually, this is more complex than than because our own system checks
transition end events to reposition the overlay. Even if unperfect,
we now have:
- User click on control button, transition starts.
- slide.bs.carousel is fired -> we enable the parent carousel instead of
the current slide (this DOM element is not moving).
- slid.bs.carousel is fired -> we know it is fired too soon, so we wait
an extra 20% of the time between 'slide' and 'slid' before retargeting
edition.
- The transition finishes, the overlay is still over the carousel and
not the active slide.
- Our extra 20% duration ends, we retarget edition to the current slide
and reposition the overlay (should not move since normally at the same
position as the carousel itself).
Part of https://github.com/odoo/odoo/pull/38997
task-2090180
Previously, the carousel and quotes carousel snippets were the only ones
that were not enclosed in section blocks. This had a number of
undesirable side effects, such as editing the anchor on the carousel
breaking the carousel functionality, and the inability to separately
choose a background for the carousel itself and individual slides.
I also used this opportunity to move controls relative to the entire
carousel onto the carousel itself rather than the individual slides. The
sizing_y (vertical padding) will however keep targeting individual
slides, as the carousel uses the height of its tallest slide, and also
because padding on the carousel will not get covered by slide
backgrounds and saty blank, which is unwanted.
Lastly, most of the snippet options for the carousel were rewritten, as
they were quite broken. There was some compatibility code for saas-3
left, some useless events were bound to the controls, even though they
were already handled through event-delegation at the document level.
Finally, most of the edition features were broken on duplicated
carousels since the onClone method wasn't reassigning most of the things
it needed to.
Part of https://github.com/odoo/odoo/pull/38997
task-2090180
Previously, when trying to enable a snippet overlay & options, the
'toggleFocus' method was called. Now the logic is separated for overlay
and options toggling so that we stop calling onFocus/onBlur method of
parent options when only a child snippet is being enabled.
For example, for a section with two columns inside, we had this behavior
before this commit:
1) Click on first column
2) -> the section's onFocus is called
3) -> the first column's onFocus is called
4) Click on second column
5) -> the section's onBlur is called
6) -> the first column's onBlur is called
7) -> the section's onFocus iscalled
8) -> the second column's onFocus is called
9) Click on another snippet
10) -> the section's onBlur is called
11) -> the second column's onBlur is called
Now, steps 5 and 7 are gone.
Related to https://github.com/odoo/odoo/pull/38997
Related to task-2090180
Purpose
=======
Like in crm, having a refusal reason to get some metrics on recruitment
+ recruitement dashboard
id=2003841
closesodoo/odoo#38467
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since commit 62c9dedafd attachments almost always require employee
user access, unless some specific flow grants super user rights. Moreover
other flows like portal checks user rights before going into attachments
management with superuser rights.
In this commit we simplify code by directly checking current user belongs
to internal employee group (or is a superuser / admin).
We consider tt is the role of controller/model using attachments to check
and grants access to attachments.
Some history of attachments management improvement (not complete, just
an overview of discussed points)
* 3620cb68a0: improve attachment management in portal;
* de7c119e66: improve message_post and its attachments management;
* 62c9dedafd: clean ACLs;
Task ID 2004031
PR #38358closesodoo/odoo#39869
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
How to reproduce:
- Create a tracked product using expiration dates and don't set the
`expiration_time` field;
- Create a receipt for this product (using "Create New Lots/Serial
Numbers") and confirm it;
- Create a move line for this product and define an expiration date;
- Valid the picking -> Traceback.
The issue was as `expiration_time` isn't set on product, the production
lot created on the receipt's validation don't have an `expiration_date`.
So, if the `expiration_date` is set on the receipt move line, the
production lot will try to get a time delta with its unset
`expiration_date`, causing the traceback.
task-2119330
closesodoo/odoo#39795
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
=======
Allow to add an attribute ``show_unusual_days="True"`` to display
some days in green, according to a linked method ``get_unusual_days``
that should be defined on the related model to return all the
concerned days for a given period.
*: hr_timesheet
project_timesheet_holidays
account
Creation of analytic lines will be done in batches instead of creating single
record by iteration. This optimization is done in order to speed up the creation.
task-1971460
closesodoo/odoo#34481
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* the employees file apparently never worked as the marital status was
updated before template files were added (respectively
0eb58775c9 and
b60de0db41)
* the purchase template was never updated to reflect the Big Demo Data Changes
(58fc4e4409).
Fixes#39074
Employees file update split off of task 2059779.
closesodoo/odoo#39823
X-original-commit: 80a2f6877378a87638c04061ceaf69965c1707c0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
Go on the accounting module, you'll find a kanban view with a few
cards including "Bank" and "Cash". Click on the Cash card.
The default import button doesn't appears because it is hidden.
The reason of this hiding is that the bank statements of type "Bank"
have a custom import method and the users where confuse. They
didn't know which is the right button for the special import so
we hid the default import button for the whole model.
But there is also a "Cash" type bank statement who doesn't have that
special import and his default import button is hidden too.
This commit checks the type of the bank statement and hide the default
import button only if the type is not "Cash".
OPW-2090477
closesodoo/odoo#39829
X-original-commit: ee45228a8532b676729bc2be686814d616e5cbb5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 6b048a8b8 most issue with trigger causing error when uninstalling a
module were solved.
But there was a particular case if the current uninstallation of modules
there was an update of `ir.model.fields.selection` to be removed. The
unlink of `ir.model.fields.selection` would cause a `setup_models` call
that would add all removed triggers back and possibly down the line
cause an trigger recomputation error.
With this changeset, we do as is already done for ir.model.fields and do
not re-initialize the registry during module uninstallation.
opw-2098915
closes#39796closesodoo/odoo#39824
X-original-commit: 0ccf2ab8e7f3edabb2d3d4c17a20829de21cca49
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
When building the MS Windows package, the PYTHON_VERSION variable is not
used and the WinPython path is hard coded in the Makefile and NSI file.
This prevent the usage of a newer version of Python.
With this commit, the PYTHON_VERSION is used to compute the WinPython
Python directory. That way, this directory can be derived from
package.py command line argument --vm-winxp-python-version.
Also the less windows binaries are not packaged anymore.
closesodoo/odoo#39821
X-original-commit: ac90d8584f99e24aed931eb5186c360f9dfbf399
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
PURPOSE
Allow karma gain tracking enabling notably display of top users based on
weekly / monthly gain in website profile.
SPECIFICATIONS
Each time a user gains karma a record is created in the gamification karma
tracking model. Scheduled activity runs to consolidate the records into
monthly gain records to avoid having crowdy table and unnecessary noise
in karma gain.
This model is made private and only accessible through some dedicated
compute methods / controllers used in website profile.
In website profile module buttons are added to see users ranking based
on their total karma (like before) but also by last week and last month
gains (using the newly introduced tracking model).
Some fixes are provided in this merge as well as tests.
LINKS
Task ID 2003505
PR #34594
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to have all karma related tests in the same file to ease finding
them back. Some tweaking is also done like using a savepoint case and ensuring
tests can always be re-run.
LINKS
Task ID 2003505
PR #34594
Purpose is to support both search term and karma gain group by in the
URL, using keep_query.
Clean some code and move karma computation to res.users model to avoid
having sql in controllers.
Also fix some display issues.
LINKS
Task ID 2003505
PR #34594
PURPOSE
Allow karma gain tracking enabling notably display of top users based on
weekly / monthly gain in website profile.
SPECIFCIATIONS
Each time a user gains karma a record is created in the gamification karma
tracking model. Scheduled activity runs to consolidate the records into
monthly gain records to avoid having crowdy table and unnecessary noise
in karma gain.
This model is made private and only accessible through some dedicated
compute methods / controllers used in website profile.
In website profile module buttons are added to see users ranking based
on their total karma (like before) but also by last week and last month
gains (using the newly introduced tracking model).
LINKS
Task ID 2003505
PR #34594
- Create a project
- Create 3 tasks in the project (top, middle, bottom)
- Set top as the parent of middle
- Set middle as the parent of bottom
We don't want to allow multi level subtasks. The behavior is not the
same if you set middle as the parent of bottom first. The "parent task"
field will not be displayed.
This commit remove the tasks who have a parent from the m2o field.
OPW-2087921
closesodoo/odoo#39810
X-original-commit: c7966b64c42940b606eaf3d985c49549928056bd
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
URLs with parameters were not correctly supported by the regular
expression.
For example, URLs with parameters were truncated before the '?'.
This patch adds support for a wider range of URLs, and checks in a test
that the parameters are correctly handled.
closesodoo/odoo#39762
X-original-commit: 616e145635eac06a0a44ab3d899f4a9e707b3ba8
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Allow users to modify a down payment invoice's properly by reflecting
the change done to the invoice (e.g. taxes, amount) on the initial
downpayment SO line when the invoice is posted. This support several
nice flows, such a allowing (partial and full) refunds of downpayments
while preserving still a meaningful 'last invoice with deducted down
payments' amount that sums up to the total of the order.
Note that this does not apply to locked orders (by definition of the
term 'locked').
closesodoo/odoo#35982
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
It is by default in pos_mercury that pending payments are removed before
syncing the order to the backend. However, this is not the case for the
newly introduced API for payment terminals in pos. In this commit, we
are implementing this pos_mercury feature as default for all terminal
payment methods.
closesodoo/odoo#35579
Task-id: 1984690
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If there is a Vantiv payment line, adding terminal payment line (e.g.
Adyen) was possible because Vantiv payment line is not recognized as
electronic payment. This commit generalizes the behavior where new
paymentline is prevented if there is a pending electronic payment.
task-id: 1984690
With the introduction of pos_adyen, pending payments are not counted in
the total payments. We are now implementing the same behavior for
pos_mercury.
task-id: 1984690
table is currently the html element that is used to display the payment
lines in pos ui. Though it is simple to use table element, customizing it
is not trivial and it requires significant effort specially when we want to
make modifications in with borders.
This commit converts the payment table to be represented by divs of grids.
This gives us more granular control in customizing the payment table.
task-id: 1984690
When there is a pending payment from a terminal payment method, and we
attempt to add a vantiv payment, an error message is displayed but is
not actually raised in the code. As a result, the code continues with
the effect of highlighting the currently selected payment to be like a
pending vantiv payment. This commit fixes the described issue.
task-id: 1984690
The previous behavior is that change is displayed at each payment
line and the remaining is displayed at the bottom. Also, total
amount is lost in the screen.
This commit addresses this issue by showing the values of
remaining amount and change at just one area of the payment
screen.
task-id: 1984690
Someone new to Linux can run into problems when some system dependencies
are missing. There is a single sentence warning talking about those hard
dependencies and it does not explain how to install them.
Added two § containing the missing `apt` commands required to install
the dependencies on a fresh debian minimal install.
closesodoo/odoo#39774
X-original-commit: f7d0022f11d63777eb88bb5f808be3c5ced88fd6
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
To prevent having holes between statements and for better usability using import and synchronization
we try to automatically set the starting and ending balance based on the previous existing
statement.
To do that, we added a new field previous_statement_id so that whenever we change the ending_balance
of the previous statement, we recompute the starting balance and ending balance of the current statement.
Also creating a new statement in between 2 others statements will automatically set the correct value
to the starting and ending balance of that statement and all the statements afterwards.
Exception: creating a statement by hand won't automatically set the balance_end_real, however if you
create one between 2 statements, the balance_end_real of next statements will be recomputed
Was Task #1880409closesodoo/odoo#38696
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
mcm-odoo