#104 user account activate/disactivate

[Steve Pugh]

This patch allows user accounts to be disactivated (and
re-activated). Once an account is disactivated, the
user cannot log in. This could be done, for example,
when a user leaves the organisation. The user is not
deleted from the database because his record may be
required for audit trail or history view purposes.

Please note, a new boolean field is required to the
"party" table and needs seting to true initially. This
can done with this SQL:

alter table parties add column active bool;
update parties set active = true;

[Steve Pugh]

user disactivation patch

[Alan Pevec]

Logged In: YES
user_id=1334257

First thing: please, pretty please, when you make any data
model change, provide a properly packaged SQL upgrade script
i.e. increase version in application.xml, register upgrade
script in src/<APP>.upgrade and put the SQL upgrade scripts
under sql/<APP>/upgrade/<DB>-<FROM>-<TO>.sql (which usually
just includes actual scripts from ../<DB>/upgrade/<FROM>-<TO>/)

2nd point: this features seem to be similar to "ability to
ban users" which RuntimeC added in r1169. Difference is that
RC checks this in UserContext i.e. for each access. Benefit
is that users get banned immediatelly even if they have
persistent cookies (Remember me). Disadvantage is an
additional DB hit for each access, that's the reason I added
config param waf.user_ban_on which is false (no ban
checking) by default.

Question for RuntimeC/Magpie: what was your user requirement
- wouldn't be enough to check for banned/inactive user only
during the login (like Bristol did here) and not for each
request? If persistent cookies worry you, you can disable
them with waf.kernel.remember_login=false

[Steve Pugh]

Logged In: YES
user_id=1271522

I haven't been including appliation.xml in my patches
because our "local" revision numbers won't necessarily match
those in the current trunk. Likewise, the problem with
creating a versioned upgrade script is that I have now way
of knowing when my patch will be incorporated into the
Aplaws trunk and therefore which aplaws versions the upgrade
will apply to. Perhaps this is an area where guidance is
required for patch submitters?

I didn't realize runtime had done a similar patch. Actually
I asked about this subject on the forum just in case anyone
had been working on it. Unfortunately no-one replied so I
assumed it was OK to write the patch. Perhaps the patches
could be "merged" with an switch to choose which method to
use, i.e. checking on every request or only at log in time?

[Alan Pevec]

Logged In: YES
user_id=1334257

Please register for the Developer role at aplaws.108.redhat.com
As said in the last APLAWS UG, I'd like to see more
developers to monitor development (via commit mailing list)
and use the trunk APLAWS+ version.
All patch contributors get the write access to the trunk and
are encouraged to merge their patches asap.
The idea is that submitting patches early and piece-wise,
we'll get them tested and fixed more quickly, in contrast
with the current approach where we have massive patches
submitted just before the release.

[Steve Pugh]

Logged In: YES
user_id=1271522
Originator: YES

Since I have now tested the "ban" feature in the 1.0.4 code, anmd there is no point having two patches that do nearly the same, and I have decided to chage my patch to provide a different but similar feature.

We also have a requirement which is to (optionally) allow users to access the content-center on an external URL. However we don't necessarily want to give this access to all users in the system. Therefore I will rename my "active" field to "resticted", and instead it will have the meaning of restricting login on certain (virtual) hosts.

Therefore I would suggest not to merge this patch into the trunk just yet.