1. Make test logs clearer & remove redundancies
Instead of having an ERROR log right when the test fails then print
the useful / relevant information at the end of the test suite,
immediately print the traceback. Keep the final summary. Also avoids
having to wait for the entire test suite to end before a dev' can know
the failure details of a specific test.
Done by working at a lower level and replacing the custom
test stream mess by a custom Result class which prints and formats the
information we want. Replace TextTestRunner by a bare-bones custom
Runner object to tie it in.
2. Provide useful location information on test failure
Leverage the work above to log the test function's failure location:
previously logging would point to within TestStream which is not
useful.
Here, on failure the traceback is used to discover the caller info and
point to the test line which fails instead. similar to unittest's
_exc_info_to_string (https://github.com/python/cpython/blob/93e8aa62cfd0a61efed4a61a2ffc2283ae986ef2/Lib/unittest/result.py#L173).
3. Replace direct logging in browser_js by raising errors
Properly marks the test as in error, and the error traceback points to
the tour definition / launcher (python side) rather than common.py
and/or module.py.
Also removes unused dbname parameter that was added in
/278ed718e9805edf088642ba10d3b7c4e5716c31/openerp/modules/module.py#L361
for nor visible reason
closesodoo/odoo#34996
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
QWeb templates that show up in the 'qweb' key of a module's manifest
now support server side inheritance and xpath evaluation
QWeb templates that show up in the xmlDependencies of a JS widget are not
impacted at all by theses changes, as they are served through the
Werkzeug sharedMiddleware
A similar syntax than ir.ui.view has been implemented in the QWeb templates
- each template must have a root node, whatever tag works
- the root node of a template must have a t-name containing the name of the template
The name -- without the module's name -- may contain dots pretty much anywhere
Though what is recommended is only underscores in template names
- if a template is to inherit from a parent, the root node has a t-inherit directive
containing either the full name of the template it inherits from which is module_name.template_name
or the name of the template, no module name necessary, if the parent template is in the same module
- there are 2 modes of inheriting
primary: copy the behavior of the parent into the template
extension: modifies the parent in place
Task: 1999528
closesodoo/odoo#33892
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
* = website_sale, website_sale_wishlist
The wishlist animation was not handling the affixed navbar and always
referring to the main one.
Now the animation will target the right navbar if we scroll down.
When the navbar is duplicated, the ids of the tags were kept which is
wrong and was producing bugs such as the wishlist button not showing up
on the floating navbar on the first product added to the wishlist and
the first issue. Now the id is removed from the clone and never used
in JS code. Its only purpose is for the xpath of the wishlist button.
When a product was added to the cart from the wishlist and the affixed
navbar was displayed, the product was hidden before the animation was
completed. This changed the height of the page and the animation went to
the middle of the page instead of the button. This is now fixed too.
task-2002122
closesodoo/odoo#34358
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, it was only possible to add attachments on documents from
the backend or by sending them by email.
It is now possible to add them also from the portal chatter, including for
portal/public users who have a valid access_token.
Part of task-37264
closesodoo/odoo#34526
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Co-authored-by: Pratima Gupta <pgu@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Add a test case to choose the best supplier.
If any product is having multiple suppliers for a different quantity,
then the system will choose the supplier based on the ordered quantity and
minimum price.
task-1947351
closes: https://github.com/odoo/odoo/pull/34049closesodoo/odoo#34049
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of this task:
Choose a vendor with the minimum price, respecting the quantity
Before commit:
The system was choosing the vendor by sequence,
But if there are any vendor having a different price for the same product,
based on ordered quantity, then the system can't choose the lowest price.
After this commit:
If there are vendors having different price based on the ordered quantity,
then the system will choose the vendor based on the quantity and lowest price.
task-1947351
closes: https://github.com/odoo/odoo/pull/34049
Since changes made on multi-company, env.user.company_id doesn't
reprsent the the current company anymore, it is only the company in
which the user will be connected by default in Odoo.
The current main company is now available under env.company, so we use
now the current company instead of the user default.
closesodoo/odoo#35129
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In this commit -
In detailed operations wizard, from and to locations should be hidden when -
1) Operation type is of 'Vendor' (From location)
2) Operation type is of 'Customer' (To location)
task-2036654
closesodoo/odoo#35062
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Since task Id 2000687 and PR #33475, karma position field is not necessary anymore
as the karma position is computed directly in the website_profile controller.
Task ID: 2001367
PR #35103
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the following faulty behaviors:
1. There is a traceback in the pos ui when the selected
customer has fiscal position that maps a tax to nothing.
To prevent this behavior, we avoid to add the undefined
tax destination.
2. When you change the customer in pos ui from someone who
has fiscal position to someone without, the tax in the
order remains to be based on the previous customer. The
tax should change to original tax of the product or
to the tax mapped by the default fiscal position of
the session. To avoid this behavior, we now set the
default fiscal position on the order when a customer has
no fiscal position.
closesodoo/odoo#34955
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
To have a better flow when a session needs to be cash controled and
really opened, we've added a state on the session which is 'new_session'
to identify the new sessions that have not been cash controled yet.
TASK-ID: 1934784
closesodoo/odoo#33948
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The view of the POS session when you close it and see all the
transactions that have been performed during the session has been
improved to clearly see the summary of the session and easily check your
cashbox at the begining and end of the session.
TASK-ID: 1934784
You can currently set a difference amount authorised in a cash journal
when a pos session is closed. This feature, allow a POS user to validate
a POS session having a difference between what you are supposed to have
in your cashbox and what you are really have. If the difference is too
big, you have to be POS manager to close the session.
We've improved the feature:
First we've moved the difference limit from the journal on POS config
and not on the journal as it is more a way that the POS is used than an
accounting configuration.
We've also added a wizard to warn a pos manager that the difference is
too big, because before the manager could always validate a session
without being warned that there can be a problem.
TASK-ID: 1934784
When you have a cash journal, you have the opportunity to use a wizard
to easily create the statement. There are two wizards, one to add money
in the journal, and one to remove money.
To simplify the code and remove some duplication, we are now using only
one wizard, that will allow to add and/or remove money from the cash
journal.
TASK-ID: 1934784
When you use a cash journal in the point of sale, you can enable the
'Cash Control' option on your pos config to be able to count the money
in your cashbox before and after selling goods in the POS.
To better manage this behavior, we've made some improvements to handle
the starting and ending of a session.
First, instead of having just some cashbox lines set on the pos config
representing the default cash fund in the cashbox, we are using an
object of type cashbox as template. This allows to use the same default
config for multiple POS config without recreating it.
Then, we've added a currency on the cashbox, which is just computed
based on the currency referencing the cashbox.
When a POS session is open, the content of the cashbox is the same as
the last closed session, to represent how a real cashbox works.
We also always have the possibility to set the default cashbox of the
POS config at the begining of a session.
TASK-ID: 1934784
When a cash journal is used in POS, we need to have accounts to post the
difference between what it's supposed to be in the cash journal and what
we really have in the cashbox.
To help the user to configure his cash journal, we've added default
accounts for cash difference in the localisation. Those default values
are stored on the company and are use for the creation of cash journals
if no values are provided.
TASK-ID: 1934784
PURPOSE
Followup of merge 4287481 .
SPECIFICATIONS
wrong_format_number is actually now called wrong_number_format. This commit
propagates this renaming through SMS code and tests.
LINKS
Task 1922187
closesodoo/odoo#35025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Followup of merge 4287481 .
SPECIFICATIONS
Display "Missing number" in recipients invalid message when not having
any number to ease user experience;
Use note subtype when logging through composer, like already done in standard
sms API method at 2b7ad217f1a55a0687ba4ec4765bc7777114aac0;
LINKS
Task 1922187
PURPOSE
Followup of merge 4287481 .
SPECIFICATIONS
Notification type is now a selection -> use 'sms' instead of True;
Fix typo in method renaming not correctly propagated to its view;
LINKS
Task 1922187
PURPOSE
Improve SMS UX integration. Followup of merge 4287481 .
SPECIFICATIONS
Fix recent SMS merge: do not display tooltip / popover about SMS information
in chatter if there was no recipients linked to the SMS message.
LINKS
Task 1922187
Since the wizard is not shown anymore (skipped to go right to file selection), we can remove it. Small refactoring had to be done for l10n_it in order to upload files with multiple invoices inside and to detect format
closesodoo/odoo#34145
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2007561
We want to avoid this intermediate screen; Instead, directly open the selection files window...
Done from dashboard button + vendor bill list view & customer invoice list view.
Purpose
=======
Having a clean policy in leave access right. If there
are some internal need or bugs, read this before decided
if it is an expected brhavior or not. It is what we want
in a standrard point of vew.
Specification
=============
Access rights Policy
--------------------
Remove Time Off - Team Leader access right
Leave_manager_id is now requried, by default it
is = parent_id for admin it is admin by default (data
employee_admin)
3 access rights:
- Internal User
- Time Off - All Approver
- Time Off - Administrator
3 fields for "manager"
- parent_id
- leave_manager_id
- manager_id on department
Department
Is just there for information. So never use it in
default filters
Rules Policy
------------
Don't forget to take the leave type configuration into
account
* no validation means automatic
* officer validation means you need to be at least
holidays_user to approve
* manager validation means anyone who is at least
leave_manager_id can approve
Internal User
-------------
In double validation mode he:
- can only do the first approval
- can see the everyone's leaves with a anonymisation of
the leave description
- can create a leave (even if leave type is directly approved)
- can refuse its own leaves (till not reported in payslip)
- can reset to draft his own leaves and reconfirm them
- can delete a leave in draft state
- can cancel a leave if the date_start is in the future
- cannot validate its own leaves
If leave type is configured in manager mode, he:
- can approve or refuse the leaves if he is leave_manager_id
If leave type is configured in both mode, he:
- can only do the first approval or refuse for the leave
if he is leave_manager_id
Time Off - All Approver
-----------------------
In double validation mode he:
- can only do the second approval
- can see, write, read all leaves and perform the second
approval.
- Can set a leaves as reported in payslip.
- Cannot validate its own leaves
- cannot configure leave type
- cannot create leaves in batch
Time Off - Administrator
------------------------
In double validation mode he:
- can do all the approvals
- can bypass all leaves (approve or refuse).
- can configure Time Off Types
- can create batch leaves
- can validate its own leaves
Menu
----
- My Time Off (access rights: internal user)
- Dashboard
- Time Off Requests
- Allocation Requests
- My Team (rename into "Everyone", access rights: internal
user. default filters on current year and group by
employee; default view: gantt can switch to list and form)
- Managers
- To Approve (internal user who are leave_manager_id
see and can approve. See only leave he has to approve
(domain))
- Time Off
- Allocation
- All
- Time Off
- Allocation
- Payroll
- Time Off to report.
- Reporting (access right: time off administrator)
- Time Off Analysis
- Report by Department
- Configuration (access right: time off administrator)
Usability
---------
- In all list of "manager menus", add actions to change
status in mass
- In leave type data:
- move Home Working from data to demo data
- There are 2 Paid time off, get rid of the company on
it and share it on all companies (keep only the one
in data)
- Leave type like this:
- Overtime Compensation/compensatory days (keep only
one of both, to avoid having 2 same leaves in
demo data). Validation by: team leader and hr
officer, no validity date
- Paid Time Off 2019. Validation by Team Leader
and Payroll Officer. Remove validity, remove 2019.
- Unpaid. Can be taken in hours. Approved by Payroll
officer and team leader. No allocation needed.
- New leave request: order of leave type in the m2o:
1. leaves where allocation are fixed by rh and remaining
> 0 and allocated > 0
2. leaves where free allocation. Where reaming is > 0
and allocated >0
3. One already taken
4. All other leaves.
- Remove the sequence widget in leave type
- The employee should get a notification when his leave is
refused "Your "leave_type_name_" planned on "start_date"
has been refused"
- from the dashboard calendar, the reset to draft should lead
to edit (avoid user has to click on edit)
- An employee should be notified when a leave is approved
"Your [leave_type_name] on [start date] has been approved"
Leave Dashboard V2
------------------
https://drive.google.com/file/d/1pMCqDlecqM7ngvmhJJdWtkG2_GiXHyIX/view?usp=sharing
Testing
-------
Everything concerning the leave requests has to be tested.
All the access rights have been reviewed and need testing.
Migration
---------
Don't forget to keep the filters in the calendar view (otherwise RIP perfomances and usability)
TaskID: 1950998
closesodoo/odoo#33813
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Enforce the domain of the UOM not by an onchange but by a domain.
Example of an issue if the domain is enforced by an onchange:
- create a order
- add an order line
- select the product
- select an uom
> the uom presented are the one from the product category.
-Save
- edit
- select an uom
> all UOM are presented even the ones of other categories
This commit enforce this new logic at most places.
task - 2003959
closesodoo/odoo#33741
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
No more modal because it's not visible and less handy. Use same behavior as
sales order portal.
Adapt the invoice style to properly adapt and align with the chatter block.
Part of task-37264
closesodoo/odoo#34360
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Pratima Gupta <pgu@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Since 1e6c3bec2c that refactored the sudo in general, the
`_document_check_access` method from portal that was supposed to return the
document in sudo mode was not returning the expected record.
It was not with the admin UID, making some code to crash, for instance:
https://github.com/odoo/odoo/blame/120f890ecf57969878399d9543b49080e7618c60/addons/stock/models/stock_quant.py#L252
Which is doing `self.with_user(self._uid).check_access_rights('read')`.
Step to reproduce:
- Install `sale_stock` module.
- Create a quotation for a portal user
- As the portal user, try to sign the quotation
- It will crash on `stock.quant` right access
closesodoo/odoo#35030
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, the signature tour (130af96dc1) would fail sometimes.
Indeed, the tour is trying to get `Thank You` on the page after the sign step
but since the modal to pay will open on top of the page, the `Thank You` would
not be found.
Purpose of the commit is to let user select only those
products which are being shared among companies or belongs to own company.
On purchase order user will only able to select those products
which are belongs to same company as purchase order or products
which are sharable by default.
task-2025168
closes: #34342
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Purpose of the commit is to make the multi company consistence with product,
sale order and order template.
So the Common Product Catalog setting is removed from generel settings
because its behavior wasn't really clean from a technical point of view
(disabling the rule on products access) and wouldn't work as well with
new multi-company logic.
The default logic of sharing products will be kept, but when someone
wants to limit products sharing, he will do so product by product, by
setting the company_id.
Also the default company_id on product will be blank so default product
will be a sharable by multi company.
and added company_id on sale templates so user can select his/her own
company or the templates which are common.
task-2025168
Closes: #34342
Having an assert that randomly breaks is quite annoying, as this assert
is not critical and breaks once every 100 - 120 builds. It can "safely"
be commented out before being fixed
closesodoo/odoo#35043
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
The default value for a many2one on res.currency should be a
res.currency object not a res.company one
closesodoo/odoo#35004
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There was an error in this tax's repartition. A tag was wrongly added to its base.
closesodoo/odoo#34245
Signed-off-by: Josse Colpaert <jco@openerp.com>
Under certain unknown conditions, the range cannot be applied and
triggered an error. In order to allow the user to keep editing, we need
to prevent the dialog from showing, hence the use of `console.error`.
If this error appears, the carret is moved to the beginning of the focused
node.
If this error appears, then bullet can generate an error (I managed to
have the bug once or simulate it by manually breaking the dom and range)
We suspect a wrong snippet custom javascript code.
see: https://github.com/odoo/odoo/pull/34188closesodoo/odoo#34871
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Let's assume a form view with a readonly many2one field with a
default value. When creating a new record, the user can click on
the many2one value, which should open the related record in a form
view (stacked in the breadcrumbs).
Before this rev., this didn't work: we actually came back to the
previous view/action in the breadcrumbs, when trying to open the
related record.
closesodoo/odoo#33172
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Backport of https://github.com/odoo/odoo/pull/34132
The test case of alipay payment is going to failed due to:
1) Now the redirect_url from the return_url is removed in commit :
https://github.com/odoo/odoo/commit/0aefe72b773a21bdd38fdc86779d3030bd5127c6
but it's still it's there in test cases so removed from test case.
2) To make the transaction done it must be in draft, pending or authorised
state but in first test case payment process the transaction state is set to
cancel and in another payment process use the same transaction again to set
it success so before use the same transaction again just set the state to draft.
task- 2005926
closesodoo/odoo#34708
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When the 'before' (resp. 'after') hook is defined on a QUnit module,
it is executed once, before (resp. after) the whole module is
executed. When the test suite is executed several times, tests that
failed in the previous execution are always executed first,
separately from the other tests of their module. In that case, the
'before' hook is executed directly (before the execution of the
failed test), but the 'after' hook is only executed once the whole
module has been executed. This means that a lot of other tests,
coming from other modules, can be executed in the meantime.
In calendar tests, we used the 'before' and 'after' hooks to catch
scroll events. So, when a calendar test failed, and the suite was
re-run, some tests depending on the scroll failed.
To prevent this, we use 'beforeEach' and 'afterEach' hooks instead,
as they are executed before and after each test.
closesodoo/odoo#34932
Signed-off-by: Julien Mougenot (JUM) <Arcasias@users.noreply.github.com>
Xavier-Do