Before this commit, when we click on social tags in the Settings,
it opens a pop-up while redirecting to the home page in the main window.
The redirection is not intended.
This is caused by href="#", which purpose is to show the pointer cursor when
hovering on the links. The issue is that href="#" redirects to the index page
on click, which is the home page.
This commit keeps the href while cancelling the redirection on click in the
main window.
Have the public user (not logged in -- user B) having a live chat with any logged in user (user A)
Having in mind that:
- (A) issues /history in his chatter to see where (B) has gone on the website
- The bus sends a kind of a "pull cookie request" on each clients
- The browser of (B) retrieves the cookie info and calls the relevant route
- That route sends the transient message for (A)
Before this commit:
The command did not work because the user of the route we end up on is the public one
hence, the search for the channel would not yield anything
After this commit:
The command does work as expected
OPW 1818732
closes#23485
On expense lines the state field was present both in the parent view
and in the child view. This was causing the javascript not to render the
widget as intended.
Closes#23496
A crash occured in several Studio tests that have just been
forwardported to saas-11.2, because of a line that hadn't been
adapted in rev. cb339842 (technically, the previous code was
correct, but it crashed when viewInfo.fields was undefined, which
doesn't happen outside the tests environment).
Before this commit, when using createDiscuss and performing
discuss.destroy, the parent widget was not destroyed.
This is an issue, because the mocked environment is attached
to the parent widget of discuss. Any call to this.getSession()
is mocked by the addMockEnvironment, and this mocked behaviour
is removed only when the corresponding widget is destroyed.
This commit overrides discuss.destroy(), so that the parent
widget is also destroyed, so that it removes the side effect on
this.getSession() from the mocked environment.
While displaying no content help, hovering over link was not displaying cursor
as a pointer type.
This bug has been introduced with the new design on nocontent helpers.
Hr_expense add several people as follower of expense reports to ensure
various responsibles are notified. However depending on configuration
same partner could be added several times in an ORM command. This makes
the unicity of partner_id for a given document crash.
This issue has been introduced at ab8f5ec95d when working on task ID 30933.
Set up a delivery method that has a country set on it, but no states
(e.g. USA)
When the client is required to fill his address info in and when he chooses USA as the country
Before this commit:
The selection field where the states are selectable is not displayed.
After this commit:
All the states of the country are selectable
The usability choice is to say that if states are not specified on the delivery method
that means all states are supported
OPW 1818591
The python/xml try to create a default value for
property_stock_account_input_categ_id for all categories, but the yaml
only try for the All category and in 11.0 this is not propagated to
child categories.
This commit make the yaml coherent with account.chart.template
generate_properties and
stock_account.property_stock_account_input_categ_id XML record.
note: second part of 1bf25fc01
property_stock_account_input_categ_id,
property_stock_account_output_categ_id,
property_stock_valuation_account_id ir.property default values on
product.category could be duplicated eg. if l10n_generic_coa was
installed before stock_account.
This did not happen in enterprise but happened in enterprise breaking
the test added in odoo/odoo@6bcf9ac2e.
- Define 2 companies A and B. Delivery methods are linked to products in
company A
- Deactivate 'Share product to all companies'
- Create a user B in Company B only
- As user B, create a SO and open the drop-down list for delivery
methods
An access error is raised.
Delivery methods should follow the same record rules than the products
they are linked to.
opw-1815490
Issue:
An additional information page is part of our shop process to allow
additional information to be submitted. If this form is left blank,
then selecting the next button allows the process to continue.
However, if data is added to the form the form freezes and the process
will not continue when 'next' is selected.
Why:
Public user can not read the field 'model' of 'ir.model' (to save the
attachments)
opw-1818592
This rev. fixes two issues with the loading (e.g. after an F5) of
form views in mobile.
First, the form view being not a mobile-friendly view, it opened
the kanban view instead (if there were one defined in the action),
whether it should have kept the form view as they don't diplay the
same things (one is multiRecord, the other isn't).
Second, after fixing the first issue, the main (multiRecord) view
which was lazyloaded when loading a form view wasn't
mobile-friendly so if the user clicked on the breadcrumbs to go
back, he landed on a list view (if the list view was the first view
of the action), whether he should be on a kanban view, which is
mobile-friendly.
This is a manual forwardport of rev. b466b3bc60.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it crashed because it tried to retrieve the
action's context (to add to the saved filter), whereas there is no
action in this case.
Actually, the action's context should never been used in this case.
What must be used is the controller's context (this mainly makes
sense for Pivot and Graph views).
Fixes#23293
This is a manual forwardport of rev. b466b3bc.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
controller in the closest instance of a ViewManager-like widget
in the SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes#23293
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
view in the closest instance of a ViewManager-like widget in the
SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes#23293
Have your OS be in Vancouver with time = 15:59:00
We are on day X
Have a next activity on a lead, scheduled for today
At 15:59:00 the next activity is not overdue
Before this commit:
Past 16:00:00 the next activity becomes overdue
This is because 16:00:00 is 00:00:00 in UTC (+8 hours)
And the next activity is scheduled for day X
But in UTC, we just passed at day X+1
Hence, the next activity being overdue
After this commit:
The next activity is not overdue, since we are actually on day X
OPW 1815323
In 3807e718 demo data were changed which affected the
bank_statement_reconciliation test which didn't expect a BILL/*/0002
line to be used instead of INV/*/0002 line.
The previous commit forbids to change the currency of a company having accounting entries, but there are some created by demo data and some tests were trying to set a different currency (to set up a fix environment). So in order to allow that in tests, we do it via a SQL query directly
Following the previous fixes in stock where we had to handle non-valued
move lines inside a valued move, the valuation of the dropshipping was
bypassed because a dropshipping move is not an in move, nor an out move.
We now value the dropshipping move always positively. We adapt the
sale_stock code that generate the anglo saxon entry to use the abs value
of the move, not -1 * value. It was done this way because all out moves
are negative.
We add 8 tests to test all the valuation cases: continental or anglo
saxon, ordered or delivered, fifo or standard.
opw-1817363
fixes#23214
Use case to reproduce:
- Create a sale order with a stockable product.
- Confirm the sale order.
- Validate the pick.
- Validate the pack.
- Cancel the OUT.
- Run the stock scheduler.
-> Picking are created from pick and ship.
The scheduler should not try to create missing pickings
for broken move's chain. Since v11, it's not possible to create
a partial mto chain that means if a chain is broken it's due to
a manual action from a user and thus we won't automatically
repair what he cancelled on purpose. That's why we won't create
a new move out in this case.
It also don't make sense to recreate a new mto chain from a
cancelled picking. Thus we had a condition in domain in order to
only take moves that make sense.
Based on preliminary work from Florent de Labarre <florent.mirieu@gmail.com>
Closes#23441#23458
OPW-1820226
This patch prevents bugs fixed at 5d463d2 to block the database.
It was preventing the autovacuum to properly clean old records.
Failing to unlink (may have various different reasons) should not block the
autovacuum to try on other models
Closes#23455
This reverts commit 7642754122.
The reason is that we finally decided to implement that in another way and we want to avoid people start using this feature as it would be replaced in next saas. Yes, I know, that sucks.
New task ID: 1823153
When creating a record in a form view of model A, and adding a line
in an inside tree view of model B(with a One2Many from A to B), it was impossible
to delete a wrong line even if the record has not been saved because the user had no
right to delete a record on model B.
opw:1819099
Christophe Simonis