I finally wrapped my head around this. (Yay!) My custom auth_user field
"account_status" is set by default to "unverified" until an administrator
verifies the account. If the user is logged-in while the admin makes the
update, the session cached value will remain "unverified" until the user
logs off, even if the value in the database has been updated. On the user's
next login, everything will be okay.
As the book states (emphasis, mine) about difference between
auth.user.account_status vs db.auth_user[auth.user_id].account_status :
auth.user *contains a copy *of the db.auth_user records for the current logged
in user or None otherwise. There is also also a auth.user_id which is
auth.user_id auth.user the same as auth.user.id (i.e. the id of the current
logger in user) or None.
And because I'm trying to use an auth decorator
(auth.requires_membership("current"), the currently logged-in user can not
access the function because his session is using the cached copy.
Just adding details to this post in case a fellow newbie find themselves in
the same situation.
In my design case registration doesn't require approval, but access to most
features are disabled until approved. I suppose, had I realized this, my
question should be, and is now:* is there a way to update a currently
logged-in user's status to reflect the latest value in the db other than
asking the user to log-off first?*
/r
On Tuesday, December 13, 2011, Nik Go wrote:
> I'm still stuck with this :(
>
> I've already deleted my database to start from scratch but I am
> encountering the same issue. For example, i deleted a record from
> auth_account (in this case record #3) but when the I run the app and run a
> trace with ipdb, my functions still return a row id 3, as if it wasn't
> deleted. But verifying with the admin app, and checking the sqlite
> database, there's no more id 3 (as to be expected). It's supposed to be
> deleted and yet the function still return the old data!
>
> db.define_table('see'
> ,Field('name',length=128)
> ,Field('classification', 'integer')
> ,Field('jurisdiction', 'reference see')
> ,Field('affinity', 'integer'))
> db.define_table('auth_account'
> ,Field('subdomain', 'string')
> ,Field('see', 'reference see')
> ,Field('status',
> 'integer',requires=IS_IN_SET(settings.account_status,zero=None))
> ,Field('manager', 'integer', default=2))
>
>
> In a function, I have this to check the value of a database
> if not session.auth_account:
> subdomain=request.env.http_host
> session.auth_account=db((db.auth_account.subdomain==subdomain)\
> &(db.auth_account.status==4)&(db.
> auth_account.is_active==True))\
> .select(db.auth_account.id, db.
> auth_account.see, db.auth_account.status).first()
>
> and it returns: *<Row {'status': 4, 'see': 11, 'id': 3}>*
>
> That is not correct since record id 3 has been deleted (from the admin
> interface, confirmed by checking the sqlite table). And if I add a new
> record (to replace id 3), the new record isn't found by the function. I
> have restarted web2py, deleted the databases, restarted the browser,
> changed browser but I get the same thing.
>
> Under what conditions would this thing happen: a function returning a row
> that doesn't exist? What are the other things I should check?
>
> On Monday, December 12, 2011, Nik Go wrote:
>
>> And the other fields are still set to "none", while their true values are
>> otherwise.
>>
>> On Monday, December 12, 2011, Nik Go wrote:
>>
>>>
>>> Here's a screenshot. Noticed that i edited the name to"GJonathan" but
>>> the response.flash retrieves it as "Jonathan"
>>>
>>> On Monday, December 12, 2011, Nik Go wrote:
>>>
>>>> I have a custom auth_user field that I could edit from admin (and I can
>>>> verify that changes are actually written in the sqlite table) but every
>>>> time I check the data from a view, the field value is always set to the
>>>> initial default values, and not whatever's actually stored in the table.
>>>> It's like the data is being retrieved from some cache I don't know about.
>>>>
>>>> I'm stumped. Has anyone experienced anything similar? This is the first
>>>> time I encountered this. What gives?
>>>>
>>>>
>>>>
