[16.0,17.0,18.0] session_db Users Sessions closes after restarting Odoo server

[stferraro]

Problem

When a user logs into the system and the Odoo server is restarted without closing the browser, the user's session (and all active sessions) are lost. This requires users to log in again after every server restart.

Steps to Reproduce:

1. Log in to Odoo with any user.
2. Restart the Odoo server (systemctl restart odoo or similar command).
3. Without closing the browser, try navigating within the Odoo system.
4. The user is logged out and has to sign in again.

Expected behavior User sessions should persist after a server restart, allowing users to remain logged in without needing to reauthenticate.

Environment

• Odoo version: 16 / 17 / 18

[victoralmau]

Ping @pedrobaeza @LoisRForgeFlow

[rousseldenis]

@JordiBForgeFlow @LoisRForgeFlow Any thought on this ?

[LoisRForgeFlow]

BTW, I tried my same example above, but instead of adding one unit, reducing it, and the qty in progres remained unchanged in both SR (5 and 7 units respectively) even when the receipt it is now for 11 units.

[victoralmau]

Some comments:

• Sorry for what was indicated in the description (already corrected), the expected value is 12.
• Corrected regarding possible rounding and added an extra use case.
• The use case would be covered to increase/decrease the amount. Important to remember that odoo does not cover the use case of reducing the quantity on a purchase order until v15 (if I remember correctly), i.e. it is not reduced on the picking.
• The previous error I think is clear, if the quantity was modified (although for now in v14 it is not possible to reduce by the odoo core) the quantity in progress was increased, now, the correct quantity is defined proportionally.

Do you need anything else?

[LoisRForgeFlow]

Some comments:

• Sorry for what was indicated in the description (already corrected), the expected value is 12.

Thanks! :+1:

• Corrected regarding possible rounding and added an extra use case.
• The use case would be covered to increase/decrease the amount. Important to remember that odoo does not cover the use case of reducing the quantity on a purchase order until v15 (if I remember correctly), i.e. it is not reduced on the picking.
• The previous error I think is clear, if the quantity was modified (although for now in v14 it is not possible to reduce by the odoo core) the quantity in progress was increased, now, the correct quantity is defined proportionally.

Sorry, I was not specific, I reduced the qty in the receipt manually by unlocking it. The qty in progress is still unchanged.

Do you need anything else?

What do you think of my previous proposal/suggestion: "maybe allocating one by one until full and them allocating all the excess to the last one might be a more pragmatic approach and less confusing". I mean what you propose is not technically incorrect, but it is a bit more confusing. Eg:

PO 14 units and 2 SR for 4 and 8 units. I would rather have qty in progress 4 and 10, than 4.66 and 9.33. I see the proportional allocation a bit confusing. What do you think?

[victoralmau]

Sorry, I was not specific, I reduced the qty in the receipt manually by unlocking it. The qty in progress is still unchanged.

But that is not enough, changing the stock move demand will not change anything because it will not call the _prepare_stock_moves() method of purchase.order.line.

What do you think of my previous proposal/suggestion: "maybe allocating one by one until full and them allocating all the excess to the last one might be a more pragmatic approach and less confusing". I mean what you propose is not technically incorrect, but it is a bit more confusing. Eg:

PO 14 units and 2 SR for 4 and 8 units. I would rather have qty in progress 4 and 10, than 4.66 and 9.33. I see the proportional allocation a bit confusing. What do you think?

I think that although it may seem more readable it is totally incorrect, if for example we have 11 and 1 it would become 11 and 2. Personally I think that all this problem happens due to linking several requests to the same purchase order line (something that can be avoided with procurement_purchase_no_grouping).

[LoisRForgeFlow]

Sorry, I was not specific, I reduced the qty in the receipt manually by unlocking it. The qty in progress is still unchanged.

But that is not enough, changing the stock move demand will not change anything because it will not call the _prepare_stock_moves() method of purchase.order.line.

Fair enough, out of the scope of this PR.

What do you think of my previous proposal/suggestion: "maybe allocating one by one until full and them allocating all the excess to the last one might be a more pragmatic approach and less confusing". I mean what you propose is not technically incorrect, but it is a bit more confusing. Eg: PO 14 units and 2 SR for 4 and 8 units. I would rather have qty in progress 4 and 10, than 4.66 and 9.33. I see the proportional allocation a bit confusing. What do you think?

I think that although it may seem more readable it is totally incorrect, if for example we have 11 and 1 it would become 11 and 2. Personally I think that all this problem happens due to linking several requests to the same purchase order line (something that can be avoided with procurement_purchase_no_grouping).

You are right about the procurement_purchase_no_grouping. However since we are dealing with this case here, we need to discuss it even if it is quite uncommon or avoidable, at the end of the day it is the reason that made you open this PR, isn't it? Back to discussion, I still like it more 11 and 2 than 11.91666 and 1.08333.

@pedrobaeza @rousseldenis thoughts? opinions?

[github-actions[bot]]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[github-actions[bot]]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.