Make an invoice for partner X
Make a payment from partner X (not using the register payment button)
On the invoice, you'll see your payment proposal
Now, reverse the move of the payment
Before this commit:
On the invoice you *still have* the payment proposal
This is because nothing reconciled the reversed entries with the original ones when they were created
After this commit:
The reversed moves are reconciled one on one with their original counterparts
And the original payment doesn't show up anymore on the invoice's proposal
OPW 1816462
OPW 1816641
Some call signatures have not been aligned with the taxes/product/partner
signature
introduced by the tax cloud module and necesary by some localization modules
Closes#23334Fixes#23333
Improves some aspect of timesheet for a better usability:
Rename "Subtask Planned hours" into "Subtasks" AND put "hours planned" next to the hours as units
changes track visibility of Deadline Planned hours so that a message will be generated when those values are changed.
Progress : it was possible to to have a progress higher than 100% when more time have been spend that the planned hours, but it doesn't reely makes sence for a progress bar.
Remaining hours should be editable: it is now possible to edit the remaining hours if needed, the field planned hours is updated in this case to keep informations consistent.
Also remove the default values of description for the subtasks when it was taken from the parent task name in some cases.
Task #58927
PR #23200
Simplification of the search method of the lines lines (for the
propositions) of the two requests in one. The sql query returns the two
matching lines without filtering after the request because we inject the
rules of access rules directly into it.
This is an optimization in terms of clarity and speed. In addition to the
fix because the previous browse does not use access rules.
Warnings are styled a bit differently than notifications, as their
background is red (thanks to classname 'o_error' on the warning
root element). This classname isn't correctly added since rev.
920df59, which changed the root element of the 'Notification'
template, which is extended by the 'Warning' template, making
qweb.js fail to add the 'o_error' classname.
The following tweaks have been applied on mobile devices:
- remove left and right arrow in control panel
- enable swipe navigation (instead of left/right arrows)
- replace 'Today' button by a calendar icon
- remove static text 'Attendees:' in events
- shorten header content in week mode to prevent them from
overlapping
- ensure that the calendar fits in the screen
Also introduce a mobile test suite for the calendar view.
Task #31449
In 5c2380e9f an issue when modifying variants values was solved when an
attribute on the product variant had "create_variant" unset.
This commit forward-port what was lost of it in 11.0, that part was
probably lost because the code was previously changed when adapting to
python3.
Without the change, the added test failed creating a new variant keeping
the existing one. With this change, 'nocreate' value are ignored when
computing new variants to create.
opw-1815226
closes#23332
Changes to a bank account should not be happening without approval and
not in an in-transparent way. In some cases, a third party can pay an
invoice for another account
opw-1817138
Steps to reproduce the bug:
- Go to Fleet
- Group by status
- Click on a vehicule
- Click on Costs
Bug: A traceback was raised because a group_by was made on the model "fleet.vehicle.cost"
for the field "state_id" and this field doesn't exist on this model.
opw:1815454
- Removed 'Invoices' and 'Credit Notes' filters.
- Removed inherited view of filters to remove the 'Not Draft' filter.
- Renamed 'Not Paid' to 'Open' filter.
- Added new filter 'Paid'.
- When click on 'Invoices/Bills' or 'Credit Notes' link of 'View'
column from 'Customer Invoices' and 'Vendor Bills' dashboard, it
should be open invoices with a specific domain instead of default
filters.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
opw-1817236
Previously, bank accounts were created at the line creation, even if the partner was unknown. That was a very weird behavior since
- that use case of a res.partner.bank belonging to no one is meaningless
- the default partner was actually set to the current'user company, which was even more wrong.
This has been already improved by https://github.com/odoo/odoo/commit/7b322d08de2b5343cdf6935a7ae4a12f1fd61958 but that first patch ignored the use case of res.partner.bank created thr$
Purpose
=======
It looks a little to restrictive to only allow bank journals on payment acquirers.
For example on could want to define a manual payment acquirer linked with a journal of type "cash".
Allow both journal types instead of only bank.
Currently the rating value coming from the rating application is stored
on the message it belongs to. However storing it is not necessary as
there is no direct search using it. Having a computed field is sufficient
for all use cases we currently have in Odoo.
Removing the store allow to gain queries. Indeed the field is not
computed anymore after each message creation meaning we save queries
by not having to check existing ratings. It allows to gain a lot of
computation as mail.message is a critical model.
On the whole community runbot when installing all modules this leads to
a gain of more than 14K queries on 585K which means 2.4% of performances
increase. Considering the code size of this optimization this is quite an
interesting result.
Looking at test_mail performance tests we gain several queries (2/3) for
each new message which is coherent with the model change.
Finally it allows to lessen the performance difference between tests done
with test mail only and tests done with other modules already installed.
This is especially simple mail thread-enable records.
Related to task ID 51523. #Closes #23294. Done with blessing of @jem-odoo .
From time to time, it happens that a developper forget to remove debuggers.
This commit adds a test to find such imports (pdb and pudb). The test
will fail if that kind of import is found. The Odoo runbot should run
this test and prevent developper from those small mistakes.
Before this commit, while performing a check on whether a customization
being imported was done using studio or not, we would assume that the
.zip would, at the very least, contain a data folder.
This is not the case as loose files can be imported and the data folder
is only generated by studio customizations.
To solve this, we walk over the whole zip instead of walking over the
data/ folder only (which may be non-existant), so loose files, files
inside the data folder and potentially files in other folders can be
parsed without raising unexpected errors.
Previously, trying to register a payment on today towards an invoice posted with a date prior to the FY lock date, was raising an error... which was completely wrong.
Previous to this rev.:
*Install stock w/ demo data
*Uninstall stock
*Reinstall stock
Result: Boom! Installation crashes.
Reason: The demo data installed with stock is not properly deleted after
the module is uninstalled, which causes issues/conflicts upon
reinstallation of the same demo data.
Solution: Remove any demo data of stock models upon installation if any
exist through a pre_init_hook, ideally this would be done by overriding
the unlink() of the affected models / setting some ondelete='cascade',
or even a uninstall_hook, however these solutions prove insufficient for
databases that are currently affected by the problem.
Fixes#22243
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
Purpose of this merge is to clean a bit various methods and remove some
dead code. All those commits come from other work-in-progress branches
in mail aiming at improving performances and reducing code size. We can
already merge some light cleaning in order to lessen diff and ease
understanding of real feature-based branches.
It contains
* some renaming in notification methods to match the _notify prefix used
in most of them;
* removal of some dead code coming from old implementations of chatter;
* removal of unnecessary context switch in email sending process;
* small cleaning of notification group methods in various addons;
It allows to gain some queries in various test_mail performance test as
stated in the test_performance file update. When notification emails are
sent 4 queries are gained with this merge. On the whole community runbot
the impact is small (about 1K queries) probably because most of email
sending part is skipped on runbot.
This merge is related to the task Id 59039. #Closes #23089.
Overrides of _notify_get_groups are used to add some buttons in notification
emails and control the display of "Access document" button. This commit
cleans some overrides :
* accounting: portal users that are not the customer have no access to the
invoice and should not have the access button;
* project: remove unnecessary override on project model and consider portal
users have access to the document through customer portal;
* sale: portal users that are not the customer have no access to the sale
order and should not have the access button;
* website_blog: display access button to everyone only if the post is
published; otherwise keep standard behavior;
* website_forum: display access button to everyone only if the post
has not been closed or deactivated; otherwise keep standard behavior;
* website_slides: display access button to everyone only if the slides
has been published; otherwise keep standard behavior;
Send methods of mail.mail model are set private and simplified. Those
methods have been written when a lot of overrides were necessary to
generate notification emails. Since then the flow has changed but
methods have not been updated completely. This commit therefore simplified
a bit the call chain and parameters.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
This commit renames some internal mail.thread methods linked to the
notification process. This is the next commit of a series aiming at
improving code readability and method finding through prefixes. See
notably cae1c3977f, cdfe479e2e and fc1348dd3d.
This commit does not change any functional feature. It does only
rename notification-related methods, using the _notify prefix to
ensure they are private and to mark they are part of the notification
process.
Commit 0d3d0e9563 added a key in context when sending emails to know
the target model name. It was used at that time to forge for footer of
notification emails.
Since that time notification emails have evolved a lot. The code based on
that context key has been removed. Context key has been transformed into a
context switch. However it is not used anymore and can be removed. It allows
to clean a bit the code and save a context switch.
This commit is purely technical and does not hold any functional change.
Purpose is to clean code in order to prepare future changes in mail
application.
This commit allows to gain some queries in mail sending process, meaning
removing context switch is interesting. One query is gained when using
the send process. Complex performance test involving several message post
gain 3 queries each.
1d57a09112 added a two-steps parent fetch when posting a message
on a discussion thread. At the time this commit was done responsible were
notified of the first thread message. It was helpful to notify them of the
original email that created the thread instead of the "document created"
generic message. Indeed for documents like leads or issues having the
original email containing the customer question is interesting when being
notified. This is why this commit was done.
However since quite a long time responsible notifications have changed.
They now receive an email notification telling they have been assigned on
a document. This commit is not necessary anymore and we therefore remove
it in order to clean a bit the message_post process.
This commit globally reverts 1d57a09112. Please note that @beledouxdenis
agreed after a long thinking.
This commit has a slight impact on mail performance tests, allowing to save
one query in some more complex test case.
- set due date based on payment terms at generation for recurring bills
- do not generate "This vendor bill has been created form POXXX" for bills that have been generated by cron
Lucas Perais (lpe)