User tests: Successful: Unsuccessful:
Steps to reproduce the issue
1) An user connects in the front end
2) He edits his profile
3) He saves it
4) When the profile form is reloaded, look the user object with the function of JFactory getUser (JFactory::getUser())
5) You can see that the groups property is null
In fact, the function getUser loads the user object from the session previously saved with the property groups set to null (function save JUser around the line 819).
Suggested solution
To prevent the lost of groups property, I suggest to save the property before save and restore it after
Labels |
Added:
?
|
Category | ⇒ | Front End |
Hi Hackwar,
Of course, I understand that the group management right is pretty inconsistent today but before it is improved, I suggest this quick, simple and sure solution to correct this issue.
In any case, can you please fix the codestyle errors that you have in your code?
I'm not sure what you're tryig to do here.
I get that you temporary store the groups to avoid it getting lost, but since the method returns shortly after and the $user object isn't passed to anything, I don't understand the purpose of it.
Can you elaborate?
There is also JUser::getAuthorisedGroups(), which should be better to retrieve the groups of your user than accessing an internal var directly.
It is difficult to explain but I going to try
1) The 'save' function of profile.php, create a temporary JUser object to bind and save the new values.
2) The 'save' function of JUser saves the values in the database and it is very important, stores also the object JUser in a session of PHP (see around the line 819 of user.php)
3) When I set the groups propertie of JUser, I change also the groups propertie of JUser in session of PHP because the set function of JSession just assigned the value (not serialize). And in PHP, the objects are assigned by reference.
4) After when I come back in the site and I use the JFactory::getUser I retrieve the object JUser saved previously in the session of PHP.
I hope my explanations are clear with my very bad english.
Last thing, I believe also the 'set' and 'get' funcions of JSession should be improved
Thank for your suggestion Hackwar. I looked the JUser::getAuthorisedGroups function and I found another function JAccess::getGroupsByUser with a param to not include the inherited user groups like the groups propertie of JUser. It is a good solution for me, thank you very much.
So, if you have a solution for your problem, can this one be closed?
I have a solution for my problem, but with this solution, I bypass the issue. The issue that I explained is not resolved in the core
Setting to Needs Review so a CMS Maintainer can make a decision if this is required in the core
Status | Pending | ⇒ | Needs Review |
Will be this fix included in some patch ?
Because i'm very afraid to modify core files, i dont' want to lose this pretty fix after next joomla update.
(I'm new to this tracking method)
Currently, no. There aren't enough tests to even consider it.
I tested the offered patch successfully as it seems to solve the problem described.
What I did before patching:
First I investigated the property groups' setting with a new created profile:
Result: ["groups"]=> array(1)
After editing and saving the profile:
Result: ["groups"]=> NULL
After I applied the patch, editing and saving the profile:
Result: ["groups"]=> array(1)
So this is why I marked my test as successful as I think and hope this is the result you were looking for.
<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="http://issues.joomla.org/tracker/joomla-cms/6370">issues.joomla.org/joomla-cms/6370</a>.</sub>
Hi Flow87,
Thank you very much for your test
Status | Needs Review | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-07 11:16:16 |
Closed_By | ⇒ | Kubik-Rubik |
You should keep in mind, that the group management right now is pretty inconsistent. There are several properties, where the group data is stored and keeping the groups in that variable actually is not the right solution. We should rewrite the whole group management thing. I would expect JUser to work something like
$user->addToGroup($group);
and that adds the user. I would also expect to have a proper$user->getGroups();
Both are not present. There is a getAuthorisedGroups() method, which reads and writes to a different internal property. So this is a larger complex.