smd_user_manager: keep large user bases under control

Bloke · 2011-07-27 22:36:20

Give yourself and your users more control. This is a complete replacement for the Admin->Users tab. Features:

Add / edit / list users, with content counts alongside each user
Search, sort, or filter the users
Quickly find accounts with certain characteristics (e.g. self-registered spam accounts with 0 articles)
Perform multi-edits: change privilege / reset pass / delete
All users can edit their own details and change their password — including smd_bio data, if v0.40+ installed
Create new user groups (a.k.a. roles) if the default six aren’t enough
Rename existing groups to more suitable names (you cannot delete them)
Modify TXP’s standard priv areas to alter what each user group can see/do
Add new priv areas (useful for custom code to save doing it in a plugin)
A “who’s online” indicator

Download the plugin and let me know as always any goodness, badness or indifference. Requires Txp 4.4.1 or higher

Revision history
————————

All available versions and changes are listed here. Each entry indexes the relevant post(s) in the thread to learn about the features.

27 Jul 2011 | v0.10 | Initial public release
03 Nov 2011 | v0.11 | Added smd_um_has_privs tag to check privs/areas ; added preference to allow editing of smd_um privs; fixed handling of users with privs=None

Last edited by Bloke (2011-11-04 00:38:56)

CeBe · 2011-07-28 06:54:08

In one word: woha-impressive-efficient-useful-so-good !

Last edited by CeBe (2011-07-28 06:54:40)

vaprea · 2011-07-28 07:42:15

Hi Stef,
i’ve successfully installed this fantastic plugin, but when i click on “User manager” i receive:

Fatal error: Call to undefined function tInput() in /…/textpattern/lib/txplib_misc.php(653) : eval()’d code on line 1173

Thank you

Bloke · 2011-07-28 07:43:39

vaprea wrote:

Fatal error: Call to undefined function tInput() in /…/textpattern/lib/txplib_misc.php(653) : eval()’d code on line 1173

You need Txp 4.4.1 to run this plugin.

jpdupont · 2011-07-28 09:41:45

What my last client need : link some users to some sections (a group of users may edit articles of some sections). Is it possible to do that actually or … in the future ?

douglgm · 2011-07-28 10:41:36

jpdupont wrote:

What my last client need : link some users to some sections (a group of users may edit articles of some sections). Is it possible to do that actually or … in the future ?

Absolutely, this would be the last pice of the puzzle as far as I’m concerned!

sacripant · 2011-07-28 11:16:05

Here is a very simple interface and very effective. Good job Steph. As always.
If I understand correctly, this plug’in allows:

Modify standard priv areas of groups with a graphical interface, similar bot_privs, or by directly editing admin_config.
But also priv areas on different tabs Plug’ins. What can be done by editing the plug’in sometimes.
Rename groups, what you can do with “wet_babble”, with varying degrees of success.
Create new groups.
Batch operations for users.

What I remember mostly is

Ability to create new groups, while the six existing aren’t enough.
Add new private areas (I still do not understand how it works)
Have a simple and effective graphical interface for the customer, if he needs to manipulate its users.

@ jpdupond
Able to limit the permissions of the groups to certain sections or categories is a feature that many TXP users expect, and this for several years. I too hope that solves with TxP5. It is always possible to hide sections using Javascript or CSS, but this is a makeup too easy to remove.

Another feature that I expect is to divide the permissions for creating users.

For example:

Authorize the “Copy Editor” to create and manage only “Staff Writer” and “Freelancer”, and has no permissions to delete or modify an “Admin” or “designer” or other “Copy Editor”.
Authorized the “Managing Editor” to create and manage “Designer” and having any permissions to the other groups.
The admin has permissions to manage all groups.

For this I have not found solution. And want to expect too much from TxP5, I’m afraid of being disappointed.

uli · 2011-07-28 20:14:23

sacripant wrote:

Authorize the “Copy Editor” to create and manage only “Staff Writer” and “Freelancer”, and has no permissions to delete or modify an “Admin” or “designer” or other “Copy Editor”.

Authorized the “Managing Editor” to create and manage “Designer” and having any permissions to the other groups.

The admin has permissions to manage all groups.

For this I have not found solution.

In the meantime, have you discovered the prefs tab and there “Assume hierarchical groups”? As far as I understood that’s pretty exactly what you describe.

uli · 2011-07-28 20:19:48

Thanks, Stef! Brilliant possibilities!
Making this into a plugin is more textpatternish than I expected. I’ll have a further play with it now :)

sacripant · 2011-07-28 20:51:18

@Uli :
Oops, my bad knowledge of English still plays me tricks

@Steph
This plug’in is amazing !

progre55 · 2011-07-29 21:19:03

Bloke

You continue to raise the bar — great plug in.

progre55

jstubbs · 2011-08-09 12:50:55

Stef, this looks like an amazing plugin. Thanks for this! A candidate for core in TXP5 perhaps?

I have had buggy behaviour so far though, not sure if its my install or the plugin. On a 4.4.1 install when I open Privs and select “list” then check the option to add this privilege to a new user group and press save, the option is not saved. Well, sometimes it saves and sometimes not. (BTW, this is on that site we have worked on together).

For non-core aspects such as “smd” or “l10n”, I can’t save any other options apart from what is already checked (again I mean for the new user group).

Awesome work Stef!

Bloke · 2011-08-16 09:30:26

jstubbs wrote:

A candidate for core in TXP5 perhaps?

Probably not, but I intend to take some of the hard work in the plugin and make it core so that the plugin can be a lot smaller! Once the privs and groups are moved to the database it makes plugins like this a lot easier to write.

press save, the option is not saved.

I’ll look into it, but I’ve not noticed it yet. Do you have any cacheing in place? Either on the server or installed by you?

For non-core aspects such as “smd” or “l10n”, I can’t save any other options apart from what is already checked (again I mean for the new user group).

This might also relate to the above, but please check that this plugin is load order ‘9’ so that all other plugins are loaded first. Then smd_user_manager takes over and alters the privs afterwards. Just a by-product of the way privs are done in Txp 4.x — and will go away when they’re eventually moved to the database. If it’s not that I’ll take a look on the site in question and try to debug it. Thanks for the report.

jstubbs · 2011-08-16 16:15:01

The plugin is indeed set to order “9” so its not that. The server Joyent does use caching as I recall, but what I have seen does not indicate that this is a problem.

Bloke · 2011-08-20 22:02:45

jstubbs wrote:

The plugin is indeed set to order “9” so its not that.

You’re right, that’s freaky behaviour. It appears I can make changes to all the core privs (forms, images, article, etc) except ‘list’ which refuses to add the privs to the new users. But if I uncheck Managing Editor I can then change the privs fine — well to a point; only one at a time, but they do ‘stick’. However, as soon as I recheck Managing Editor they get reset. And with the smd_ and l10n_ ones, again, you’re right: they just won’t commit no matter what.

This is very strange because it works fine on my dev site (although that’s not running MLP). I can see no reason why MLP should interfere with smd_user_manager but at the moment I’m out of ideas. I’ll try debugging it at some stage so if you see weird screen output floating around that page, it’s just my meddling paws.

The only possibility I can think of — and this is a very long shot — is that it’s because we’ve defined the two new user accounts in the admin_config.php file and for some reason it’s borking the plugin. In theory, once the accounts are created in smd_um, they should no longer be required in the core file. But I don’t suggest deleting them from the file until we’re sure the groups are registered in the plugin.

Can you check the smd_um_groups table and see if the two new groups are in there? If not, visit the plugin’s Groups subtab and Save the list, then check again. Once they’re definitely in that DB table you should (emphasis: backup database first!) be able to remove the two new user groups from admin_config.php. I’m not sure if that’ll make any difference, nor do I know if it’ll affect the custom code that relies on user ID ‘7’ (again: shouldn’t make any difference) but it might be worth a shot.

If it’s not that I guess it’s down to figuring out if there’s a bug in the plugin or an incompatibility with some other plugin or MLP. A puzzler for sure.

Textpattern CMS

Textpattern CMS support forum

#1 2011-07-27 22:36:20

smd_user_manager: keep large user bases under control

#2 2011-07-28 06:54:08

Re: smd_user_manager: keep large user bases under control

#3 2011-07-28 07:42:15

Re: smd_user_manager: keep large user bases under control

#4 2011-07-28 07:43:39

Re: smd_user_manager: keep large user bases under control

#5 2011-07-28 09:41:45

Re: smd_user_manager: keep large user bases under control

#6 2011-07-28 10:41:36

Re: smd_user_manager: keep large user bases under control

#7 2011-07-28 11:16:05

Re: smd_user_manager: keep large user bases under control

#8 2011-07-28 20:14:23

Re: smd_user_manager: keep large user bases under control

#9 2011-07-28 20:19:48

Re: smd_user_manager: keep large user bases under control

#10 2011-07-28 20:51:18

Re: smd_user_manager: keep large user bases under control

#11 2011-07-29 21:19:03

Re: smd_user_manager: keep large user bases under control

#12 2011-08-09 12:50:55

Re: smd_user_manager: keep large user bases under control

#13 2011-08-16 09:30:26

Re: smd_user_manager: keep large user bases under control

#14 2011-08-16 16:15:01

Re: smd_user_manager: keep large user bases under control

#15 2011-08-20 22:02:45

Re: smd_user_manager: keep large user bases under control

Board footer