View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005657 | OXID eShop (all versions) | 1.05. Users | public | 2014-02-18 12:21 | 2024-01-31 15:19 |
| Reporter | d3 | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | 4.7.5 / 5.0.5 | ||||
| Summary | 0005657: oxUser should not be deleted if exist in database | ||||
| Description | A 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 | ||||
| Tags | Comments, Internationalization Rework, Product domain and basket rewrite, User Management | ||||
| Theme | Not defined | ||||
| Browser | All | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
| related to | 0005308 | resolved | jurate.baseviciene | New Account Registration doesn't work after newsletter Registration |
| related to | 0004945 | confirmed | SvenBrunk | oxuser does not use oxcounter |
| related to | 0002777 | confirmed | HR | Newsletter - Users already subscribed for newsletter shouldn't be set to oxdboptin = 2 when they subscribe again |
| related to | 0005717 | confirmed | HR | Link for newsletter subscription can be reused |
|
|
I think that this behaviour is also related to the feature "order without registration". |
|
|
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. |
