[19.0][MIG] auth_oauth_multi_token: Migration to 19.0#890
[19.0][MIG] auth_oauth_multi_token: Migration to 19.0#890OCA-git-bot merged 20 commits intoOCA:19.0from
Conversation
Allow multiple oauth login at the same time.
* cleanup, improve, docstrings * add tests
Nothing special. Just making linters happy and splitting the readme. @Tecnativa TT25619
Otherwise lookup is slow when there are many users.
Otherwise you can't delete a user.
This is cosmetic only, because this field is not used when auth_oauth_multi_token is installed.
cdeae04 to
d23fa90
Compare
CRogos
left a comment
There was a problem hiding this comment.
Code LGTM, but not tested.
Some commits could be squashed.
d23fa90 to
6fb0711
Compare
|
@CRogos Thanks for the review! |
|
This PR has the |
|
@pedrobaeza do you mind to check if we can merge this? Thanks in advance! |
pedrobaeza
left a comment
There was a problem hiding this comment.
AFAIK, you are changing the setting from the user to a general system parameter, so it's a huge change. Why?
Because in 19.0 users do not have such field anymore |
|
This is not something of Odoo 19, but of this module: And you are removing it in the migration. |
|
It doesn't matter. You just need to add the field in that new page. |
|
I disagree, if Odoo moved all the configuration related to OAuth there, I think it makes sense to follow the same path, to keep it consistent. However, I am open to change it and appreciate your feedback. Do you mind if we ask @simahawk (as the creator of the PR which added this module) for his thoughts, and I will happily update the code if he agrees with you :) |
|
That's not really true. What you are showing is the general provider configuration, not each of the OAuth specific user data. Odoo has simply hide that information on the user in 19 (according to what you are showing in the screenshots), but they are 2 different granularity levels. |
|
Odoo completely removed the page: odoo/odoo@edc6562 |
|
But I insist, they are 2 different granular levels. Previously, the max logins configuration was per user. Now you are putting it once for the whole system. It doesn't matter if the page is visible or not on the user. You are changing the configuration granularity. |
|
that's correct, I know, actually it would have been easier to include the field in the "Security" tab of users. But I decided to refactor it because I didn't think that having it per user is really that useful in this case. |
|
The question is that this is something outside the migration scope, as it's something more that can even be done in any other version. And not only that, this doesn't contain a migration script to handle possible inconsistencies: what happen if a system has all the users to have 100 max, and you are resetting that to 10? Or if there are some with 100, and another with 10? For that reason, I think it's better to limit the migration to copy this as is, and place the user field on the possible best place (agreed that the page where it was located has been removed, but that page only contained info, and this is a configuration field), and leave the discussion for a separate PR. And in general, on migration PRs, it's not convenient to do heavy refactorings/improvements that are outside of the scope of the upstream changes. |
|
You convinced me :) |
6fb0711 to
e337a86
Compare
|
@CRogos @thomashaunschmid86 do you mind to check it again? |
|
What a great day to merge this nice PR. Let's do it! |
|
Congratulations, your PR was merged at 6baf478. Thanks a lot for contributing to OCA. ❤️ |



Uh oh!
There was an error while loading. Please reload this page.