As a followup to my last posting. Since a username is undeletable and
unrecyclable. I think that this is a serious shortcoming of the system.
One solution entails the creation of 2 additional fields, createdByPartyId
and lastModifiedByPartyId, for each entity that stores references to the
UserLogin Entity. This solution would places less emphasis on the
userLoginId in favor of partyId for auditing purposes. This implies that
createdByUserLogin and lastModifiedByUserLogin would be more for storing
what the username was at the time representing the party that initiated the
transaction for the entity in question. In other words, the
createdByUserLogin and lastModifiedByUserLogin would simply be used for
storing usernames rather than be used for referencing the the UserLogin
Entity. Since the username might not even exist during a given time. Whereas
the createdByPartyId and lastModifiedByPartyId would always be valid.
This would permit the usernames to be deleted and even recycled for future
use.
The (createdByPartyId/createdByUserLogin/createdDate) triplet and
(lastModifiedByPartyId/lastModifiedByUserLogin/lastModifiedDate) triple
would be unique enough to identify the correct party for auditing purposes
over the life of the ofbiz system. Given that in an ERP system, the party is
not likely to be deleted.
What are the Consequences?
-This option requires a _lot_ of entities to be modified and hence
potentially cause system instability.
-creation of createdByPartyId and lastModifiedByPartyId and appropriate
relations to Party Entity.
-destruction of relations from affected entities to the UserLogin Entity
(??? I don't know how the entity engine would react to this change???)
-Code needs to be adapted to treat createdByUserLogin and
lastModifiedUserLogin as username holders and use createdByPartyId and
lastModifiedByPartyId to reference the Party Entity.
How would it affect existing ofbiz customers?
-After the new fields in the database is created, a "./ant" command
would
be run to populate the createdByPartyId and lastModifiedByPartyId fields
This would seem like a pretty big job. :-(
YinT wrote:
>
> I figured that was the reason why username deletions would be discouraged
> since this is an ERP system and auditing related matters are essential.
>
> Given the fact that usernames are not deletable and can only be disabled,
> wouldn't it cause problems related to running out of usernames to assign
> to subsequent employees. I.e. over time, there would be less and less
> available usernames to assign to new employees.
>
> Also given that usernames cannot be recycled for another employee and
> given that employees come and go, has no company ever encountered such a
> problem so far?
>
> Thanks
>
>
> Carsten Schinzer wrote:
>>
>> Some reasoning:
>>
>> I think deletion is not recommended, because there are plenty references
>> to
>> users, even when they are no longer active. Check e.g. references in the
>> CMS, Accounting etc. Frequently, on a certain action when it is done by a
>> certain user, this is tracked for auditing purposes. Remember, this is
>> ERP
>> business, not necessarily only e-commerce.
>>
>> Auditing (knowing exactly who did what action when) is a pretty important
>> feature in larger businesses where responsibilities are shared etc. And
>> hence maintaining the user history from ever since the first day you
>> started
>> your ERP system is vital.
>>
>> Regards
>>
>>
>> Carsten
>>
>>
>> 2009/8/7 BJ Freeman <[email protected]>
>>
>>> you can deactivate the user in the partymgr.
>>>
>>> buzlite sent the following on 8/7/2009 5:18 AM:
>>> > Hello,
>>> > Does ofbiz allow created usersnames to be deleted?
>>> > Thanks
>>>
>>> --
>>> BJ Freeman
>>> http://www.businessesnetwork.com/automation
>>> http://bjfreeman.elance.com
>>>
>>> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
>>> Systems Integrator.
>>>
>>>
>>
>>
>> --
>>
>> Best
>>
>> Carsten Schinzer
>>
>> Waisenhausstr. 53a
>> 80637 München
>> Germany
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Deleting-usernames--tp24863799p24874691.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
