JUser Plugin: Data source for Group Element

[rob]

note that this is not at all due to Bauers post but due to an outstanding ticket raised by Troester:

A user group element has been added to github - allowing you to select mutliple user groups

The form juser plugin has been updated to enable multiple group attribution, IF this element is used. Default group assignment is still limited to one group.

 

[rob]

note that this is not at all due to Bauers post but due to an outstanding ticket raised by Troester:

A user group element has been added to github - allowing you to select mutliple user groups

The form juser plugin has been updated to enable multiple group attribution, IF this element is used. Default group assignment is still limited to one group.

 

[black.be3]

thank you rob/hugh for this remarkable effort for this.
it work... again, than you very much
but on form view, i think you left debug code
select = Array ( [12] => 12 ) select = Array ( [12] => 12 )

and if we edit existing user, it still asking for password to save record (we don't want to change existing password)

 

[cheesegrits]

Ooops, forgot to push my changes up for that. I'd removed the debug code a day or so ago. Should now be in github.

Note that I had a few issues with the new usergroup element, although i think they may be specific to my setup. Just make sure you test thoroughly before putting it on your live site.

Strange about the password. I haven't had any issues with that. We should simply ignore it on edit, if the password field is blank.

Do you have 'sync on edit' set?

If you want to post a shot of your juser plugin settings, I'll try with the exact setup you have, see if I can replicate that.

-- hugh

 

[black.be3]

Do you have 'sync on edit' set?

Yes I did. I'll attach my setting screenshot as soon as posible.

 

[Bauer]

Baur,

The juser plugin works just fine. We simply haven't had time to implement the ability to add the user to multiple groups on creation.

And as I have explained to you many times, we prioritize new feature additions primarily based on the number of users requesting them. So far, this is the first request I can recall for that ability.

I am also totally confused by your objections to us offering to add new features on a paid basis. This is what we do for a living. Nobody has EVER, in the history of Fabrik, complained about us offering to implement features on a paid basis, if it's something they need in a hurry, and isn't on our immediate road map.

Consider this a last warning. If you continue to launch these kinds of unfounded, factually inaccurate, personal attacks on us, I will simply ban you from these forums. I've had enough.

-- hugh

Just shows how much I pay attention to these forums anymore. (I guess I pretty much "had enough" too?)

What?s there to be confused about? I?ve explained numerous times where my logic comes from ? I only question yours.

It would be like Microsoft putting out a beta version of MS Office 2013 and ignoring glaring bugs that are turning off potential new customers because they are too busy adding special bells and whistles to appease certain ?paying customers?.

Probably for every ?paying customer? you have, there are a handful of others ?trying out? your product. It?s much easier to lose a potential customer than it is someone who has already invested in your product. Those people already understand many of the ?issues? and ?rules? that go along with Fabrik.

I understand where the money is coming from, and the importance of supporting your existing customers. But you also have to understand the importance of a ?first impression? ? then weigh the value of your efforts toward building a better ?first impression? or lapping at the boots of some trivial ?customer?s request?.

BTW ? I replied to you in this post a few weeks ago, mentioning that I was about to Subscribe to Fabrik Support ? but was lost as to what would be most appropriate choice for me (because of the poorly designed Subscription Page). I'm still waiting for a reply on that.

So there's another place where I question the "priorities" around here - and the value of "first impressions". All I could think of at the time was, "I wonder how many hundreds of other people have got to this page and changed their mind?"

I'm only trying to stop you from continuing to shoot yourself in the foot. If that gets me banned - so be it.

 

[troester]

Nice usergroup element.
A little issue: if more than one group is checked, the element is empty in list view (it should display all groups or - as Joomla does if there are more than 2 groups - "Multiple groups")

and if we edit existing user, it still asking for password to save record (we don't want to change existing password)

I can't see a password problem: did you use the standard password element? did you add a validation?

 

[cheesegrits]

I'm seeing warnings from the J! html usergroups code when creating a new user, probably because we're not providing a default (empty) array of values.

Which also raises the issue that we need a default for the usergroup element.

-- hugh

 

[black.be3]

did you add a validation?

Ah... yes.. I forget use not empty validation, it must be because of that..

 

[cheesegrits]

I'm also not seeing multiple usergroup selections being saved into the Fabrik form. They get applied to the J! settings for that user, but not saved in the form itself. Which I think is because the element extends the single value element model class (plgFabrik_Element), rather than the list element model class (plgFabrik_ElementList). The latter is the one designed to handle elements that can have multiple values, like checkboxes, radiobuttons, dropdowns, etc.

So as far as I can tell, when processToDo() runs, and fetches the value to store in the table, it's getting an array rather than a JSON encoded string.

Playing around with it now.

-- hugh

 

[cheesegrits]

Ah HAH!!

I was wrong, the standard element class will JSON-ify an array, from storeDatabaseFormat().

My issue was, I'd changed my original group_id element (field, int) to a 'usergroup' element, and the default $fieldDesc in the 'usergroup' element was set to INT(11). So it never changed the underlying field type, so was trying to store ["2","6"] as an integer, which naturally resulted in 0 being stored.

Committing a change, with $fieldDesc set to "TEXT".

-- hugh

 

[cheesegrits]

Still think we need to be able to set a default on the 'usergroup' element though, which I'll look at later. Right now, it's time for dinner, then my weekly dose of Sunday night blues down at Ye Olde Kaffee Klatsch Sunday Night Blues Jam.

-- hugh