[kforge-dev] delete undelete purge

John Bywater john.bywater at appropriatesoftwarefoundation.org
Fri Nov 4 11:00:04 UTC 2005


Just to say that I've got delete, undelete, purge working well for 
Projects, People, and Members of projects.

(I had to find and move ConfigHelper.py back out from the gforge branch, 
because it is still used by kforge/system.py... I didn't realise because 
of the .pyc, but then happily the auto test broke...)

I also fixed up lots of tests to call delete() and purge() on fixture 
Project, People, and Members, and did various other things like making 
sure that you can't register a project (or person) with a unixname (or 
username) of a deleted project (or username) (...because then you 
couldn't undelete with a name collision), and making sure you still 
aren't given edit access for a project that you have a deleted 
administration membership for.

A description of changes:

A Domain Object may now be 'stateful'. It does this by inheriting from 
the StatefulDomainObject class.

The state (at the moment) can be either 'active' or 'deleted'. (Perhaps 
we also want 'unapproved', and 'suspended' states?)

A stateful Domain Object is created and used in the same way as before 
(with a call to create() on a register) .

Created objects are immediately in the 'active' state.

If you call delete() on such an object, you won't see it in the old 
register anymore.

This is because the registers of stateful objects only have 'active' 
objects. However, such 'active' stateful registers are composed with a 
'deleted' register, and an 'all' register, as attributes.

The 'all' registers are used to check name availability for new 
registrations. The 'deleted' registers are used to provide undelete and 
purge access to deleted objects. The 'active' registers 
(registry.projects, registry.persons, person.members, and 
project.members) are used to provide the same behaviour as non-stateful 
Domain Objects to clients, that is a registered item isn't in the 
register after that item has been deleted.

To undelete a deleted stateful object, get a reference to the object 
with register.deleted[key], and then call undelete(). You should be able 
to see it again in the register.

To permenantly destroy a deleted object, call purge(). Calling purge() 
on an active object has no affect.

Similarly, calling delete() on a deleted object also has no effect.

Please remeber that, as before, calling delete() on a non-stateful 
Domain Object will permenantly destroy the record of that object.

Please note that deleting a Project, or Person, will now cause all 
active memberships to be deleted, but undeleting a Project or Person 
will (rightly I think) not undelete all deleted memberships. Purging 
either will delete and purge all Members.

Please also note that plain (non-stateful) objects that are aggregated 
by stateful objects will be untouched when the stateful object is either 
deleted or undeleted, but will be deleted (and thereby destroyed) when 
such a deleted stateful object is purged. These are services and 
licensings for a Project, and sessions for a Person.

Hope this makes lots of sense. :-) The code seems to be working fine.

The only undelete possible from the web interface is requesting to add 
to a project a member that was previously deleted. The result is that 
the role of the deleted member is preserved. I guess this should really 
give a warning that this person was already a member of your project, 
and support undeletion of deleted members in another way?

Anyway, I thought that only project admins should be able to undelete a 
deleted project member. But a person can delete one of their own 
memberships. Not sure who should be able to purge, probably just the 
service provider.

John.

PS I fixed the "defaulting of member role by integer" issue by making 
use of the initialiseKwds() method in the Member register. I did this at 
first in the command, but that's too high. And I think it's OK for 
registers to call other registers (in this case the roles registry).





More information about the kforge-dev mailing list