Reason: bkpaas_auth already declares time_zone as a supported user-info field and already stores it in LoginToken.user_info, but DjangoAuthUserCompatibleBackend.connect_to_django_user() drops it when converting the bkpaas_auth.models.User into the project’s Django AuthUser. That makes any downstream app using the compatible backend unable to read request.user.time_zone.
I’d keep our local subclass as a production hotfix, but file an upstream issue/PR so we can remove the shim after upgrading. The upstream fix should probably copy all relevant transient user-info fields, at minimum:
db_user.display_name = getattr(user, "display_name", user.username)
db_user.tenant_id = getattr(user, "tenant_id", None)
db_user.time_zone = getattr(user, "time_zone", None)
Maybe also review chinese_name, avatar_url, email, etc., because bkpaas_auth.models.AbstractUserWithProvider.USERINFO_FIELDS includes more fields than the compatible backend currently propagates. For our immediate bug, time_zone is the concrete missing field.
bkpaas-python-sdk/sdks/bkpaas-auth/bkpaas_auth/backends.py
Line 180 in 6197621
Reason:
bkpaas_authalready declarestime_zoneas a supported user-info field and already stores it inLoginToken.user_info, butDjangoAuthUserCompatibleBackend.connect_to_django_user()drops it when converting thebkpaas_auth.models.Userinto the project’s DjangoAuthUser. That makes any downstream app using the compatible backend unable to readrequest.user.time_zone.I’d keep our local subclass as a production hotfix, but file an upstream issue/PR so we can remove the shim after upgrading. The upstream fix should probably copy all relevant transient user-info fields, at minimum:
Maybe also review
chinese_name,avatar_url,email, etc., becausebkpaas_auth.models.AbstractUserWithProvider.USERINFO_FIELDSincludes more fields than the compatible backend currently propagates. For our immediate bug,time_zoneis the concrete missing field.