smd_user_manager: keep large user bases under control

Bloke · 2011-09-01 13:35:33

Teemu wrote:

I have manually added some fields to the txp user info and the database table.

Is there a reason you did that instead of using smd_bio, which does the hard work for you? The latest beta works with smd_user_manager.

How could I display a select field with lets say two options?

Look at the functions selectInput(), checkbox() and radioSet() in lib/txplib_forms.php. For select lists you set up an array of the values you want:

$select_options = array(
   'key1' => 'value1',
   'key2' => 'value2',
);

And then pass that array as the 2nd argument to selectInput(); — the 1st arg is the select name as used in the HTML form, and the third arg is the value want to be selected by default.

Hope that helps.

Teemu · 2011-09-01 14:03:09

Thanks Stef for the prompt answer.

The reason I’m doing this the hard way, not with smd_bio, is that I’m using mem_self_register and ign_password_protect.

Where do I put that array? I think I have to get that selectInput(); insidea table row and cell, right? It doesn’t work if I put the array inside the row or cell function:

.tr( fLabelCell('Membership', '', 'membership'). td( selectInput('membership',$select_options,'') ) , ' class="membership"')

Bloke · 2011-09-01 14:11:51

Teemu wrote:

The reason I’m doing this the hard way, not with smd_bio, is that I’m using mem_self_register and ign_password_protect.

They should all work together in harmony. Is there some incompatibility I don’t know about? If so I’ll fix it if you let me know what’s not working.

Your users can register themselves with mem_self_reg, receive a password, log in using ign_pw_protect (or via the Txp standard login + rvm_privileged) and then you can present them with a form to allow them to alter their own bio. smd_user_manager allows this by default from the admin side, and the new smd_bio has input controls that allow you to build your own input form to capture updates to the fields — either on the public side or via an admin-side dashboard. It’s experimental and still requires mem_form at present, but it should work.

It doesn’t work if I put the array inside the row or cell function

It should do but you need to either put it in directly, or set the $select_options array up before you start to render the labels and cells. The second method would look like this:

tr(
	fLabelCell('Membership', '', 'membership').
	td(
	  selectInput('membership',array( 'key1' => 'value1', 'key2' => 'value2' ),'')
	)
	, ' class="membership"'
)

Teemu · 2011-09-01 14:33:12

I didn’t know that smd_bio could provide the public side updates. I will definitely take a look at that. Email notification to the site admin when user updates fields from public side form, should be possible with smd_bio and mem_form?

And thanks for the code above, it displays the select field with the options. It shows always the first option as selected, could it be possibility to display the saved value instead?

Bloke · 2011-09-01 14:37:14

Teemu wrote:

I didn’t know that smd_bio could provide the public side updates.

Well, it’s still in development so it’s not finished yet.

Email notification to the site admin when user updates fields from public side form, should be possible with smd_bio and mem_form?

Ummmm, dunno. Not thought about that. If you trust your users enough to allow them to edit their own bio info, I can’t see a reason for needing to tell an admin of that fact. In a site of 10000 users, that could quickly grow tireseome. But please feel free to enlighten me to a use case and I’ll consider it.

could it be possibility to display the saved value instead?

Sure, just supply the key you want selected as the 3rd argument. You’d have to read the value of the current setting from the database somewhere further up the code and then put that variable name in where you have the '' now.

Teemu · 2011-09-01 15:15:52

Bloke wrote:

Ummmm, dunno. Not thought about that. If you trust your users enough to allow them to edit their own bio info, I can’t see a reason for needing to tell an admin of that fact. In a site of 10000 users, that could quickly grow tireseome. But please feel free to enlighten me to a use case and I’ll consider it.

I know it sounds a bit odd, but the reason for needing it to this client is their member mailing list. So, if a member changes their email address, it is crucial to them to know.

I have thought about mem_postmaster, but integrating that to all this… that goes way beyond my knowledge.

jpdupont · 2011-10-11 05:34:11

The smd_switch_role plugin don’t list the new groups created with smd_user. Normal ?

Bloke · 2011-10-11 05:50:15

jpdupont wrote:

The smd_switch_role plugin don’t list the new groups created with smd_user. Normal ?

Try changing plugin load order so smd_faux_role comes after smd_um.

jpdupont · 2011-10-11 11:09:15

Ok ! I must set smd_user to 8 and faux_role to 9.
But since I create a “limited” group, allowing access to admin>change password area, it’s impossible to switch again to Admin role without phpMyAdmin.

Bloke · 2011-10-11 13:56:00

jpdupont wrote:

since I create a “limited” group, allowing access to admin>change password area, it’s impossible to switch again to Admin role without phpMyAdmin.

Have you tried putting smd_faux_role in ‘permanent select list’ mode by altering the line at the top of the plugin to something like $smd_faux_position = '750, 0';? That way it always appears in a fixed screen location and you don’t need to set privs for it.

Last edited by Bloke (2011-10-11 13:56:16)

Bloke · 2011-11-04 00:38:40

New version 0.11 is out. Features:

Added a public side container tag <txp:smd_um_has_privs> (which bears some striking similarities to ruud’s rvm_privileged, ahem). It allows you to check if the current logged-in user matches the given names / groups / areas so you can take action on your public-facing page (or dashboard) if a user has been granted access to some newfangled priv area (e.g. gymnasium, staff_room, whatever). Very handy for controlling access to locked-away content.
Added a pref allowing you to alter the privs of the plugin itself from the Privs panel.
Fixed a glaring oversight if you tried to set a user’s privs to None: you received Restricted Area if you tried to do that. In addition, nobody was permitted to edit any users with 0 privs (you had to use the multi-edit tool to set their privs to something else first).

Please report any goodness / badness with this version here. And let me know if you’re tackling any cool projects with custom priv areas: would be great to see them and the new public tag in action.

georgeM · 2011-11-16 05:14:15

Hi Stef, I recently commented on your remote_file plugin which is great, so please forgive me for battering you about another thing with user_manager.

First off, I love it, and it really works well…however, I am trying to figure out how to configure it in such a way that I can deny other authors’ Articles, Images, Files, Links, etc. from appearing in the list view when logged in as a low-permission user. I tried to see if there was something like “file.view” and “file.view.own”, but there is not. I hope I am explaining myself well, but again, just trying to figure out if it’s possible to configure this plugin in such a way that I can restrict a user to seeing ONLY their articles/files/images/etc. in the list view for each of those (of the admin area).

Hoping to hear your thoughts! Thanks in advance,

- George

Textpattern CMS

Textpattern CMS support forum

#25 2011-09-01 13:35:33

Re: smd_user_manager: keep large user bases under control

#26 2011-09-01 14:03:09

Re: smd_user_manager: keep large user bases under control

#27 2011-09-01 14:11:51

Re: smd_user_manager: keep large user bases under control

#28 2011-09-01 14:33:12

Re: smd_user_manager: keep large user bases under control

#29 2011-09-01 14:37:14

Re: smd_user_manager: keep large user bases under control

#30 2011-09-01 15:15:52

Re: smd_user_manager: keep large user bases under control

#31 2011-10-11 05:34:11

Re: smd_user_manager: keep large user bases under control

#32 2011-10-11 05:50:15

Re: smd_user_manager: keep large user bases under control

#33 2011-10-11 11:09:15

Re: smd_user_manager: keep large user bases under control

#34 2011-10-11 13:56:00

Re: smd_user_manager: keep large user bases under control

#35 2011-11-04 00:38:40

Re: smd_user_manager: keep large user bases under control

#36 2011-11-16 05:14:15

Re: smd_user_manager: keep large user bases under control

Board footer