Deleting usernames?
Locked
 
|
Hello,
Does ofbiz allow created usersnames to be deleted? Thanks |
|
|
No, but you can enable/disable a username.
On Fri, Aug 7, 2009 at 5:48 PM, buzlite <[hidden email]> wrote: > > Hello, > Does ofbiz allow created usersnames to be deleted? > Thanks > -- > View this message in context: > http://www.nabble.com/Deleting-usernames--tp24863799p24863799.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > > |
|
|
In reply to this post by wt@teksavvy.com
Hi,
in webtools yes, but it's not recommended, i think. Check relations of userlogin https://demo904.ofbiz.org/webtools/control/ViewRelations?entityName=UserLogin&USERNAME=admin&PASSWORD=ofbiz Each relation may block delete of userlogin(username). ya Dňa Pi, 2009-08-07 o 05:18 -0700, buzlite napísal: > Hello, > Does ofbiz allow created usersnames to be deleted? > Thanks |
|
|
In reply to this post by wt@teksavvy.com
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. |
|
|
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 <[hidden email]> > 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 |
|
|
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
|
|
|
In reply to this post by c.schinzer
I use email addresses as login.
however considering you have at least 26 characters to the power of 26-1 that is a lot of combinations. buzlite sent the following on 8/7/2009 6:30 PM: > 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 <[hidden email]> >> >>> 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 >> >> > -- 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. |
|
|
In reply to this post by wt@teksavvy.com
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. :-(
|
|
|
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 <[hidden email]> >>> >>>> 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. > |
|
|
In reply to this post by wt@teksavvy.com
Simplier and much better solution is add some deleted flag, for example
column "deleted" to entity UserLogin. This don't broke reference to UserLogin and hide unneeded userlogins. ya Dňa Pi, 2009-08-07 o 20:28 -0700, buzlite napísal: > 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 <[hidden email]> > >> > >>> 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. > |
|
|
Well,
having said that this is related to an ERP system earlier: Large companies (where this may cause a problem in the first place) typically apply naming policies for their accounts. So users do not have free choice of their account names. If you need your customers to auto-create their accounts (a very typical e-commerce-shop scenarios) their unique account is sufficiently specified by their mail address as was said earlier on this thread. Alternatively, alike many free mail-providers, you could have your users specify their wish and come up with alternative solutions if that userid is not free any more. I personally think that for an ERP system, any critical fundamental ResourceId should NOT be re-usable. Think of others like e.g. a WarehouseId, a CompanyId ... even down to more "volatile" entity-ids like , a ProductId, a ContentId, a DataResourceId etc. That's why an Id is a unique Id anyways, i.e. if it is not unique within the scope of the running environment (at least, if not Global), why is it considered an Id? Kind regards Carsten |
|
|
In reply to this post by Ján Valkovič
There is already a disabled flag that is used for this. -David On Aug 10, 2009, at 3:17 AM, Ján Valkovič wrote: > Simplier and much better solution is add some deleted flag, for > example > column "deleted" to entity UserLogin. This don't broke reference to > UserLogin and hide unneeded userlogins. > > ya > > Dňa Pi, 2009-08-07 o 20:28 -0700, buzlite napísal: >> 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 <[hidden email]> >>>> >>>>> 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. >> > > |
|
|
In reply to this post by David E. Jones-2
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
|
Re: Deleting usernames?
|
|
In reply to this post by wt@teksavvy.com
Deletion of username is not possible but disabling any username is
possible. as this will not allow the person to login with that username. This can be done by editing a username, then through the bottom panel 'Update UserLogin Security Settings'. It asks for 'Enabled' field user have to select N, then select the 'Disabled Date and Time from Calendar'. then clicking at Save button will not allow the party to login with same credentials. If you need any further support on how to do this, please feel free to email us at ofbiz@palinfocom.net -- Best regards, Ajay S PIC Technologies, Mohali
|
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |