View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003218 | OXID eShop (all versions) | 1.05. Users | public | 2011-09-03 01:43 | 2015-05-04 15:34 |
| Reporter | Adrian.Kirchner | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.5.1 revision 38045 | ||||
| Fixed in Version | 4.5.6 revision 40808 | ||||
| Summary | 0003218: oxUser::addToGroup() stores wrong entity in oxUser::_oGroups attribute | ||||
| Description | Instead of adding the oxGroups instance to the class internal $_oGroups attribute, addToGroup() stores the relation representation oxObject2Group instance in this attribute as you can see here: http://docu.oxid-esales.com/CE/sourcecodedocumentation/4.5.1.38045/oxuser_8php_source.html#l00803 This misbehavior causes major problems for all group related tasks such as oxUser::removeFromGroup() and makes user group based sql statements useless (see oxActionList::_getUserGroupFilter()) if they are processed at the same request as addToGroup() was called. | ||||
| Steps To Reproduce | $oUser = oxNew('oxUser'); $oUser->load('oxdefaultadmin'); $oGroup = oxNew('oxGroups'); $oGroup->setId('newgroup'); $oUser->addToGroup($oGroup->getId()); foreach($oUser->getUserGroups() as $sGroupOxid=>$oGroup) { printf("%-9s - %-14s - %-32s\n", $sGroupOxid, get_class($oGroup), $oGroup->getId()); } // ignore this -> only for reproducibility oxDb::getDb()->Execute("DELETE FROM oxobject2group WHERE oxgroupsid = 'newgroup'"); Expected result: ---------------- oxidadmin - oxGroups - oxidadmin newgroup - oxGroups - newgroup Actual result: -------------- oxidadmin - oxGroups - oxidadmin newgroup - oxObject2Group - 82061831685d3f8bfb82f192914e1 | ||||
| Tags | No tags attached. | ||||
| Theme | Both | ||||
| Browser | All | ||||
| PHP Version | any | ||||
| Database Version | any | ||||
