View Issue Details

IDProjectCategoryView StatusLast Update
0005657OXID eShop (all versions)1.05. Userspublic2024-01-31 15:19
Reporterd3 
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product Version4.7.5 / 5.0.5 
Target VersionFixed in Version 
Summary0005657: oxUser should not be deleted if exist in database
DescriptionA newsletter customer subscribes and an entry in oxuser will be saved (without Password and Salt).
Please mind the link in the conformation e-mail.

If the customer decides later, he want to register/buy with register, the handling of oxuser::createuser deletes the entry in DB and creates a new one.

Why does the code delete the entry instead of loading it?

The comments are contrary to the code oxUser::createUser() :

// user without password found - lets use
if ( isset( $sOXID ) && $sOXID ) {
    // try to update
    $this->delete( $sOXID );
} elseif ( $this->_blMallUsers ) {
  ...
}

It could be:

// user without password found - lets use
if ( isset( $sOXID ) && $sOXID ) {
    // try to update
    $this->load( $sOXID );
} elseif ( $this->_blMallUsers ) {
  ...
}

a similar ticket was already opened: https://bugs.oxid-esales.com/view.php?id=5308
TagsComments, Internationalization Rework, Product domain and basket rewrite, User Management
ThemeNot defined
BrowserAll
PHP VersionNot defined
Database VersionNot defined

Relationships

related to 0005308 resolvedjurate.baseviciene New Account Registration doesn't work after newsletter Registration 
related to 0004945 confirmedSven Brunk oxuser does not use oxcounter 
related to 0002777 confirmedHR Newsletter - Users already subscribed for newsletter shouldn't be set to oxdboptin = 2 when they subscribe again 
related to 0005717 confirmedHR Link for newsletter subscription can be reused 

Activities

martinwegele

2014-02-18 15:02

reporter   ~0009517

I think that this behaviour is also related to the feature "order without registration".

Sven Brunk

2023-11-24 10:43

administrator   ~0015931

The reason for this is data privacy: If we load an entry that has been created by a user, we can't be sure that the user is really the same person who created the entry. During the phase where the user needs to verify his account, in some cases he would be able to see the data that was created by the other user.
I will leave this issue open and assign it to the pending rewrite to address this this anyway, since I think I know where you are coming from.
As soon as we have confirmations from both newsletter and shop user, we can start to work on the same data.