changing a user's user group in the backend doesn't seam to sync correctly

[joit]

Hugh,

I changed the user group for a registered user in the backend. If you login the front end with the admin user I provided please go here:
/161121/benutzer-f8-2fgpsd5hckc60n1q

you see, that user vendor8 is in the vendor user group. If you view the details it's the same. This is not correct because I changed the group for this user to vendor-premium. You can see this displayed correctly if you click the edit symbol.
So there are different values for the user group displayed while editing the form or viewing the details.

Note that this works correctly if I change the user group in the front end.

"Sync on Edit" is set to yes in the juser plugin.

What could be the reason?

Thanks
Hannes

 

[troester]

I changed the user group for a registered user in the backend

Via the Fabrik form or via Joomla's user handling?

 

[joit]

In Joomla's user handling

 

[troester]

Yup, that's what I thought.

"Sync on edit" is sync on edit.
List and details view are displaying what is stored in your Fabrik list.

If you use Joomla's user handling in backend this only modifies the #__user entry, not the record in your Fabrik list.
Fabrik doesn't know about it until you edit this record.

So you must use your Fabrik form in front and backend to modify the user group.

 

[joit]

Ok, thx!
It's just funny that it behaves correctly if I open the record for editing.
It's only wrong in list and details view...

 

[troester]

"Sync on edit"

 

[joit]

ok but now I have a problem. I used to set the user group element to hidden in its options to prevent a normal user to play around with it. This seems to be saver than to hide it with Javascript.
But I can't set it to hidden because a super user should be able to change the group of a user.
So I tried to restrict the access on form (add) to super users. But this way it isn't filled out at registration (user register with user group guest).

What can I do?

 

[cheesegrits]

Just to confirm the "Sync on Edit" behavior. With this option enabled, when you load the form for edit, we use the corresponding values from the #__users table for that user, rather than the ones stored in the Fabrik table. HOWEVER, they are not updated in that record unless you save it. So you can open for edit, see those user table values, but if you don't save the form, they won't get updated.

Are you defaulting the usergroup element to the value of the desired group? Even if an element is ACL protected, any default you set on it should get applied when adding a new form. If that's not happening, let me know.

One alternative, which is what I suggest to anyone doing this kind of thing, when dealing with forms that run juser, is don't rely on ACL's / hiding for normal users vs admins. Have two copies of the list/form. One for users signing up, one for admins wanting to create / modify users, and set your elements up accordingly. So on the user one, you might set things up so you don't even specify a "Usergroup field", just use the "Default usergroup" setting under Options to set it.

-- hugh

 

[joit]

Just to confirm the "Sync on Edit" behavior. With this option enabled, when you load the form for edit, we use the corresponding values from the #__users table for that user, rather than the ones stored in the Fabrik table. HOWEVER, they are not updated in that record unless you save it. So you can open for edit, see those user table values, but if you don't save the form, they won't get updated.

Thanks, got it. Is there any performance or security issue with this feature enabled?

Are you defaulting the usergroup element to the value of the desired group? Even if an element is ACL protected, any default you set on it should get applied when adding a new form. If that's not happening, let me know.

This seems to be the case. I use the menu's new form feature you implemented a some days ago.

One alternative, which is what I suggest to anyone doing this kind of thing, when dealing with forms that run juser, is don't rely on ACL's / hiding for normal users vs admins. Have two copies of the list/form. One for users signing up, one for admins wanting to create / modify users, and set your elements up accordingly. So on the user one, you might set things up so you don't even specify a "Usergroup field", just use the "Default usergroup" setting under Options to set it.

OK, so I probably just copy the list and then all elements will be linked?

 

[cheesegrits]

Thanks, got it. Is there any performance or security issue with this feature enabled?

Not that I can think of, although as Troester said, you should really only use the Fabrik form to update those profile fields, rather than relying on the sync feature.

This seems to be the case. I use the menu's new form feature you implemented a some days ago.

Ah, you mean the "Additional Query String" stuff? No, that won't work. You can't override a default on an ACL protected element via the query string. Otherwise there'd be no point in ACL protecting it, if someone could just set it on the query string.

What you could do is something like this in the element's default:

$myGroup = $this->app->input->get('your_query_string', '');
if (in_array($myGroup, array('5', '7', '11'))) {
   return $myGroup;
}
return '';

So you could add &your_query_string=7, or whatever you want to call it, in the menu item's query string, read that in the (evaled) default for the element, and restrict what values can be used. Just don't use the actual element name as the query string key, as I'm pretty sure we just remove it from the request array if that element is ACL'ed.

OK, so I probably just copy the list and then all elements will be linked?

Yes.

-- hugh

 

[joit]

OK, I duplicated user and userdetails list and unlinked the usergroup element. Now I'm not sure what to do with it for the normal user group element. Does this
"don't even specify a "Usergroup field", just use the "Default usergroup" setting under Options to set it"
mean the settings in the screenshot I attached?
Or should I use another element plugin?

BTW, thanks for the awesome support guys! I didn't expect to get so much help this weekend

 

[cheesegrits]

No, I meant in the juser form plugin. You can either select an element to use which will define the usergroup(s), or under Options you can just predefine a group you want them added to.

But I'm not sure what you are needing to do, whether you can just specify a single group, or if you need to preset the group depending on the link they clicked.

-- hugh

 

[cheesegrits]

The usergroup element is really only useful if you want users to select the group(s). And typically, you'd only allow admins to do that when creating an account for other people.

If you just want to pre-set a group, either use the juser setting, or set a default in an ACL protected, hidden field element. If you need to set that from the query string, use the method I explained above, of getting the query string value in some eval'ed default code.

-- hugh

 

[cheesegrits]

BTW, thanks for the awesome support guys! I didn't expect to get so much help this weekend

I'm trying to clear the decks so I can do a release build on Monday or Tuesday.

So make the most of it, as I'll be busy early in the week.

-- hugh

 

[joit]

If you need to set that from the query string, use the method I explained above, of getting the query string value in some eval'ed default code.

OK, just not sure what I set as query string. My extra query in the menu is
"userdetails___user_group=abc" for clients and
"userdetails___user_group="xyz" for vendors.
Now what should I use?

 

[cheesegrits]

Reread the post where I explained that. Doesn't matter. Anything you want, as long as what you put in the menu settings matches what you fetch in that default code. Just don't the element name.

Hugh


Sent from my HTC 10 using Tapatalk

 

[joit]

ok, I did it and it partly works. Let me tell you step by step what I did to confirm please

• I set the normal user group plugin to field
• set form (add) ACL to geust so I can check it
• pasted exactly the code you gave me in options -> default

$myGroup = $this->app->input->get('your_query_string', '');
if (in_array($myGroup, array('vendor group', 'client group'))) {
   return $myGroup;
}
return '';

• I did a test register with both user group and it works.
• Then I hided the user group away with form (add) ACL set to nobody
• Then I get this error: syntax error, unexpected 'your_query_string' (T_STRING), expecting ';'

shouldn't that be ok with with the default code?

 

[cheesegrits]

Yes, it should be.

I just had a look, and I think you forgot to select "Yes" for "Eval" on the default.

I set it to Yes on one of the elements, but I'm not sure how to test it, so let me know if that works.

-- hugh

 

[joit]

registration works now!
But the group that users register with is wrong. It depends on what I set in the access form(add) field. If I set it to "public" all is good. If I set it to my "nobody" level (no user group assigned to that), users register with group 2 (registered).

Any idea?

 

[cheesegrits]

Hmmm. I'll have to experiment and get back to you.

It's possible juser is running before the encyrpted, read only element values get added back to the form data.

-- hugh