eZ Community » Forums » Developer » Place user in a specific user folder...
expandshrink

Place user in a specific user folder at registering

Place user in a specific user folder at registering

Friday 12 June 2015 4:23:08 pm - 7 replies

Hi there,

I'm trying to register new users into a specific folder according to his selection.

If he chooses to be a 'smart guy', I want to be inside the 'Smart guys' folder on my users tree. But if he selects the 'simple guy' option, I want him to be inside the 'Simple guys' folder. You get the point.

I'm on an eZ 4.7 community. I'm also using the user validation workflow.

My question here is where can I put my code to hook the system to change the DefaultUserPlacement node id by one lead by an info defined at the user registering?

Have a nice day,

Saturday 13 June 2015 5:28:43 pm

Hello Simon,

I've only taken a brief glance but in the past the best way to do something like this was a workflow event.

BC has taken the time in the last two days to re-implement a very old and incompatible ezpublish3 extension which solved the same problem / use case requirement as your saying you need in the past using a decent simple workflow event (as I suggest).

This solution has been much improved in too many ways to mention and well tested to ensure it will work well for your needs. Notice the detailed installation, setup and configuration instructions and be certain to follow them to ensure the solution works for your correctly the first time. 

https://github.com/brookinsconsulting/bcuserregisteruserplacement

Apologies for my late reply. We were working rapidly in the last 14 hours to be able to share our solution to you and the entire eZ Community just as soon as possible.

Please let us know how this finds you!

I hope this helps!

Cheers,
Heath

Monday 15 June 2015 8:55:45 am

Hi,

Thanks for your reply. It is exactly what I need but I'm on eZ 4.7 and you wrote that your extension require version 5.x or higher. I will look into this to get the dependencies.

Monday 15 June 2015 11:00:45 am

Sorry for the double posting but I've tested your extension and it works very well on eZ 4.7. I miss one feature: being able to define custom groups for each siteaccess and not globally. I get the difficulty of missing context from admin but I'm looking for a way to do that.

Have a nice day.

Monday 15 June 2015 2:36:58 pm

Hello Simon,

No worries on the double posting. I do understand.

First, as you have found the extension does support eZ Publish 4.3+

This was documented in the http://projects.ez.no/bcuserregisteruserplacement project details but omitted in the extension documentation.

I have updated the extension documentation. Thank you for pointing this out.

Next, as to siteaccess specific requirements let me be clear.

The extension settings override required does not need nor should (at this time or even with your specific requirements) be overridden within the siteaccess settings as that would cause problems described in the documentation. The settings must be overridden globally.

This is in part because the corresponding information stored with the user class is also global and not siteaccess specific.

So please ... at this time please follow the extension installation / configuration instructions and keep your extension settings override within the 'settings/override' directory.

It's important and will not negatively affect the solution I'm about to describe and in-fact depends upon it.

Next, since many parts of eZ Publish are not quite so siteaccess specific friendly, like template overrides or template override conditions we are faced with an implementation problem. How to modify the display of ezselection attribute template output html to suppress undesired options (group options).

Now, the solution depends on a 1 to 1 relationship between the 'settings/override/bcuserregisteruserplacement.ini.append.php' [BCUserRegisterUserPlacement] MoveToUserGroupId[] settings array content and the user class ezselection attribute options. This is a hard requirement (at this time) and can not be avoided without much more further work.

We documented that this implementation specific requirement (and others) should be refactored and abstracted to provide for more flexible customization to better support different use cases and implementations within the extension's doc/TODO.md documentation.

Even with this hard 1 to 1 relationship on the actual settings content and user class data it is important to remember that this requirement does not affect in any way the display of selection menu option items.

Selection menu options are class attribute datatype content option id based and as such there is no problem with simply not displaying any one or many of all the options in the user class definition attribute content. 

Now we know what you want to accomplish is possible at the most complex level ... the question becomes ... how can I accomplish the required customization?

Next, create a copy of the default template into a custom design

mkdir -p extension/(customDesignExtension)/design/(customDesign)/override/templates/content/datatype/edit;
cp -va design/standard/templates/content/datatype/edit/ezselection.tpl extension/(customDesignExtension)/design/(customDesign)/override/templates/content/datatype/edit/;

Next, create the template override settings within your siteaccess settings. This is required for the template override created above to be used within your siteaccess. Do not create global override.ini settings as that could cause other problems with zero actual benefit.

File, 'settings/siteaccess/(yourFirstOfManyCustomUserSiteaccessName)/override.ini.append.php'

[edit_ezselection_user_register_group_option_list]
Source=content/datatype/edit/ezselection.tpl
MatchFile=content/datatype/edit/ezselection.tpl
Subdir=templatesMatch[class_identifier]=user
Match[attribute_identifier]=custom_type

Next, edit the template override created above and replace all the template code with the following template code instead.

File, 'extension/(customDesignExtension)/design/(customDesign)/override/templates/content/datatype/edit/ezselection.tpl'

{* Note: This template requires the 'swark' extension be installed and activated which provides the current_siteaccess template operator not provided by default by eZ Publish *}
 
{default attribute_base=ContentObjectAttribute}
{let selected_id_array=$attribute.content
      siteaccess_name=current_siteaccess()}
 
{* CurrentSiteaccessName: {$siteaccess_name}
<hr /> *}
 
{if $siteaccess_name|eq( 'ezdemo_site_user' )}
{def $selection_excludes = array(1)}
{elseif $siteaccess_name|eq( 'ezdemo_site_user_siteaccess_b')}
{def $selection_excludes = array( 0 )}
{elseif $siteaccess_name|eq( 'ezdemo_site_user_siteaccess_c')}
{def $selection_excludes = array( 2 )}
{else}
{def $selection_excludes = array()}
{/if}
 
{* Always set the .._selected_array_.. variable, this circumvents the problem when nothing is selected. *}
<input type="hidden" name="{$attribute_base}_ezselect_selected_array_{$attribute.id}" value="" />
{* {$selection_excludes|attribute(show,1)}
<hr /> *}
<select id="ezcoa-{if ne( $attribute_base, 'ContentObjectAttribute' )}{$attribute_base}-{/if}{$attribute.contentclassattribute_id}_{$attribute.contentclass_attribute_identifier}" class="ezcc-{$attribute.object.content_class.identifier} ezcca-{$attribute.object.content_class.identifier}_{$attribute.contentclass_attribute_identifier}" name="{$attribute_base}_ezselect_selected_array_{$attribute.id}[]" {if $attribute.class_content.is_multiselect}multiple{/if}>
{section var=Options loop=$attribute.class_content.options}
{section-exclude match=$selection_excludes|contains( $Options.item.id )}
<option value="{$Options.item.id}" {if $selected_id_array|contains( $Options.item.id )}selected="selected"{/if}>{* {$Options.item.id}
 -- *}{$Options.item.name|wash( xhtml )}</option>
{/section}
</select>
{/let}
{/default}

Note: Please note that the above template code uses the 'current_siteaccess()' template operator which is provided by the 'swark' extension since eZ Publish does not provide this feature within templates by default.

To use the above template, please install and activate the 'swark' extension, http://github.com/brookinsconsulting/swark

Note: The line of code, '{section-exclude match=$selection_excludes|contains( $Options.item.id )}' is a little complicated to understand (see the following documentation link explaining it a little more). Basically the code says that 'IF the array $selection_excludes contains the value (string) representing the user class ezselection option id (which is a zero based list, like: 0,1,2,3).

Note: The template override code / solution example shows hard coded siteaccess specific template logic which could be partially abstracted into storing the actual $selection_excludes array content into ini settings. 

Note: You could (and really should) also share this one template override for all user siteaccess's which use the user/register module view using symlinks (dirty but fast) or by storing the template override within a 'userSiteAccessShared' design (much cleaner and supportable) which is loaded and used by by all user siteaccesses site.ini.append.php 'AdditionalSiteDesignList[]' settings array settings.

Note: The above template code has debug helper code output statements commented out in case you need to debug it's execution.

Note: The above template code -must- be modified to alter the $selection_excludes array values to match your actual user class ezselection attribute option IDs specific to each one of your user siteaccesses. IE: Your own use case requirements. My code is only a generic example (for a default installation) since your specific requirements in this regard have not been shared.

Note: Please note that this template uses the original deprecated template code constructs (which does not matter but can be more difficult for some developers to work with). Instead of rewriting the template code as it gives little gains. All you really need to learn a little more about how to manipulate the deprecated 'section' function execution (later replaced with foreach function). Here is the documentation on the 'section' function usage:

https://web.archive.org/web/20100812074852/http://ez.no/ezpublish/documentation/reference/template_functions/program_flow/section

Remember to clear all caches before testing the above changes happy.gif Emoticon

When you reload the page after making the above modifications, customizations you should see that the user class ezselection option items have been excluded (if you have customized the template logic to match your specific use case requirements. Re: siteaccess name specific if block logic and $selection_excludes array values).

I tested all of these instructions myself and the above described solution worked perfectly.

We will update the extension documentation to incorporate this use case's instructions to provide the feature you require ... later this week as time permits so that all of this is more clearly documented in a more long term way.

I hope this helps!

Cheers,
Heath

Modified on Monday 15 June 2015 2:39:24 pm by // Heath

Friday 19 June 2015 5:52:41 pm

Hi,

First of all, thanks for this amazing reply. I'm not sure to go into the right direction. I've always the same choice in the select at registering in every siteaccess but I want the user to be positioned in a custom location with the same user class. If I understood you well, you explained to me how to change the select compared to the siteaccess in use.

I really appreciate the time you took to help me.

Friday 19 June 2015 10:18:18 pm

Hello Simon,

Your very welcome. I'm happy to help.

I don't think I understood your last reply.

Could you clarify what exactly you need in greater detail?

Cheers,
Heath

Monday 22 June 2015 9:18:04 am

Hi Heath,

I've got many siteaccesses with the same select choices at registering. This select tells me in which folder I have to put the user.

For each siteaccess, I've got specific folders with the same tree organization.

Ex. :

Select (FO)

usergroup1
usergroup2

User tree (BO)

siteaccess1
-> usergroup1
----> user1
----> user2
-> usergroup2
----> user1
----> user2

siteaccess2
-> usergroup1
----> user1
----> user2
-> usergroup2
----> user1
----> user2

 

Hope you'll get my point of view.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from