Thanks for bringing up the PCI standard. It did not come to mind for me to be more specific about my post. I understand the this is important for users of ofbiz where credit card info is exchanged.
I was really referring to usernames assocated with parties that are in the organization (ie. employees, consultants, etc). Given that is the scenario, does the PCI spec somehow explicitly prevent a system from deleting usernames or is it just a matter of being able to identify a particular party for auditing purposes. In other words, if the system can uniquely identify a party via a partyId/userLoginId combo, would this suffice for auditing purposes. Granted that for external users, I totally agree with you that a usernames should always be associated with a particular external user and username deletion should not be an option. Would a solution where parties working for the organization can be deleted and/or reassigned. Whereas parties that are considered external to the organization should not. Thanks David E Jones-4 wrote: > > > On Aug 7, 2009, at 9:28 PM, buzlite wrote: > >> >> 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. > > Well, keep thinking. Maybe you'll loop back around to why this is a > good idea. As for the namespace, consider that with case-sensitive > alphanumeric characters you only need 6 letters to cover 56 billion > possibilities. This would include lots of inconvenient combinations, > but you get the idea... it's more than enough to cover all people in > the world, almost enough for 10 accounts for each person. > > In short, history and auditability is more important than deleting and > recycling users. In fact it's also something to watch out for if you > want to be compliant with PCI and other standards (aside from it just > being a good idea). > > -David > > >> 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. >> > > > -- View this message in context: http://www.nabble.com/Deleting-usernames--tp24863799p24936266.html Sent from the OFBiz - User mailing list archive at Nabble.com.
