Hi Ludwig,
I doubt one scenario has to exclude the other. Both should be able to
coexist. The reason I'm in favour of also implementing complete deletion
is because of the simple fact that it will no doubt be a necessity in
some environments. For us at Erasmus I'm leaning more towards
deactivation instead of plain deletion, but there might be issues with
that on other levels ... something for the "other people" to determine.
Best regards,
Hans
On 1/04/2011 9:30, Ludwig Theunis wrote:
Hi all,
I'me a little bit worried about that deleting a user would also imply
that also all his objects will be deleted.
Because this would give problems, depending on how things are organized.
For example if you have a course, on which two teachers, course
administrators, are working to getter, both deliver content to the
course. As I understand the system, the object published in a course
is originated in the repository of the user creating them.
At some point one of the course administrator leaves, (he is retiring
or even worse, he died in an accident :-), I think its only normal
the user will be delete from the platform. So everything he ever
contributed will be deleted???
Is this correct...
I think when a user is deleted the repository of the user would have
to stay, only, the reference to the user would have to be deleted.
For us this is an very importing behavior because we use the platform
to let users collaborate. Users can contribute to the system at a lot
of places, he/she write's an evaluation of an particular event for
example; So it can be used in the future. When the user is deleted the
infor should stay.
keeping all users for ever on the platform is also a concept I don't
like, because than at one point you will get out of readable login
names that students can keep in there minds.
regards,
Ludwig
2011/4/1 Hans De Bisschop <[email protected]
<mailto:[email protected]>>
Hi all,
Pure looking at things structurally when deleting a user the
following should happen:
1. Unlink all his objects
2. Delete all his objects (perhaps take a CPO export of his
entire repository beforehand as a final backup?)
3. Contact all applications / packages with a request to delete
all references to user x (which isn't all that unsimilar
from the object unlink)
If and when all that has been implemented everywhere, the user
itself could be deleted and there shouldn't be any problems.
Practically speaking it's a loooooooooot of checks that need to be
executed and even more statements that need to be executed to
actually make it all happen. Te easy way out is to not actually
delete the user but deactivate him. That might work in some cases,
depending on your company's policy, but it does not remove the
need for an actual delete in those cases where it is explicitly
needed and/or requested.
Best regards,
Hans
On 01/04/2011 08:56, Sven Vanpoucke wrote:
Hello All
I would like to discuss the deletion of a users in chamilo 2.0.
At this point the user his content objects are NOT removed
because they would cause a lot of issues where the content
objects are published or used in other content objects. It's
important that we define some kind of procedure that should
happen when a user gets deleted. What happens with his content
objects, what happens with the references to the user id's in all
the other tables (tracking, subscriptions etc...).?
At this point i'm pretty sure that when you delete a user, the
system will break on some places because of the display for the
username without the check if the user still exists. I
implemented a new function in the userdatamanager which gets the
user's fullname by user id which returns the fullname if the user
exists and User unknown if the user doesn't exist anymore but i
didn't have the time / resources yet to change this feature on
the entire platform. If you are developing new features i would
ask you to now use this function, or at least check if the user
still exists in the platform to avoid breakage.
--
*Hans De Bisschop*
Hoofddeskundige ICTO | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
[email protected] <mailto:[email protected]> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
Dev mailing list
[email protected] <mailto:[email protected]>
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
http://lists.chamilo.org/listinfo/dev
