usergroups element and juser form plugin

[troester]

This related to Fabrik3.0 and Fabrik3.1
Setup:
form with juser plugin:

• usergroups element selected for usergroups,
• default group selected
• sync on edit

Issues:
on creating a new user
the default group isn't taken (and you can't set a default in usergroups element settings)
(this is only in Fabrik3.0; Fabrik3.1 is setting the (single) default user group)

on edit:
usergroup element doesn't sync with Joomla settings (is empty instead of showing the usergroups) but on save it's overriding Joomla settings

 

[jfquestiaux]

Yes, the usergroup element is in "read only" mode: it shows what are the current usergroup settings for the user, but if you change something, it's not reflected in the Joomla usergroups.
I was planning to edit the plugin to change that, but have had the time yet to do it.
Shouldn't be hard though as there are Joomla methods that can be used.

 

[troester]

The main problem: if creating a new user it will assign no group at all (because usergroup element has no default and the juser "default user group" setting is ignored (in F3.0).

Next problem - it is not readonly.
In details view it is "syncronising", i.e. it's showing the Joomla user groups (even if they have been changed in Joomla after the last Fabrik save).
In list view it is not "syncronisng" but showing the last groups set via fabrik form (i.e. the ones stored in the Fabrik list/table which is not linked to #_users).

If editing the form (as superadmin) it's showing only one group (I assume the one with the lower ID), so if you save without any change, any additional group assigned to this user will be gone.

So if you want to use juser plugin you can't use the usergroup element.
And with a normal field element storing the usergroup you can't handle users with multiple groups.

 

[joomlamate]

Any update regarding the Usergroup plugin ?
In the meantime, any advise on how to make a normal field to display the usergroup in the list, would be nice...

 

[lcollong]

Hi everybody on the forum,

Hope Rob is doing well at the JoomlaDays in Paris !

Apparently we have the same problem with the usergroup element. We use it together with the juser form plugin to allow some members management. If we switch "sync on edit" on, the usergroup is not correctly populated with the right values (only one group). As we have users belonging to several groups we need to display the user joomla details together with administrative ones and to save the record. If the usergroup field is not populated the right way while opening the form we lose all the group assignments on the submit (whatever are the rights of the current user).

Wouldn't it easier to use a customized DBjoin mutli chekbox plugin as the #_users_usergroup_map acts as the n-n intermediate table that the fabrik plugin build in such case ?

 

[lcollong]

Forgot to say that we are under J3.3/F3.1 very recent github. Maybe wrong forum ?

 

[cheesegrits]

Probably the same issue, though.

I've done some work a few months ago on the usergroup element, but really just a bandaid to stop it from doing something Really Bad (allowing people to set themselves as Super Admins), and the short term band aid for that pretty much broke the element.

We really need to just pull it entirely apart and start again, this time with the built in assumption that it will be used in conjunction with the juser form plugin. The code as-is was really just a simple minded re-write of a widget that displayed / selected single groups in 1.x.

I'll try and find the time to do this soon, but it'll be in 3.1, not 3.0. If we can back port the fixes without too much additional work, all well and good, if not ... 3.0 is pretty much "it is what it is" now.

-- hugh

 

[lcollong]

Hi Hugh,

Sorry for posting in the wrong forum. We are running F3.1 under J3.3 so very interested to test your work.

I think that the "sync on edit" should populate the usergroup element with whatever are the group to which belongs the edited user. However, indeed, the plugin should still prohibit to record any modification of the groups which do not correspond to the editor rights. But, one solution could also be to not show up all the groups on the "sync on edit" (on load) but only those which are potentially editable by the current editor rights. However it should still leave the non editable already assigned groups untouched upon submit.....

Just some thoughts ....