smd_user_manager: keep large user bases under control

tye · 2012-07-31 03:41:53

Hey Stef – how’s things?

Just trying to figure out if I am trying to use this correctly.

I’ve just taken over a site which has setup a a system where users are added via this plugin and assigned users privs, then the same user privs are entered into an article custom_field – the idea being that only users with the same user privs as the article will see the article, otherwise a message.

I’ve tested printing out the custom_field on the same form I am using this code and it works, but every time when I login with the user with the same privs, I get the error message:

<txp:smd_um_has_privs group='<txp:custom_field name="privs" />'>

Photos

<txp:else />

<p>Sorry, you do not have the correct access privileges to view these photographs</p>


</txp:smd_um_has_privs>

tye · 2012-07-31 03:46:03

Ps – this is a tag trace:

<txp:smd_um_has_privs group='<txp:custom_field name="privs" />'>
			[attribute 'group']
			<txp:custom_field name="privs" />
			[/attribute]
			[<txp:smd_um_has_privs group='<txp:custom_field name="privs" />'>: false]
			<txp:site_url />
		</txp:smd_um_has_privs>

Bloke · 2012-07-31 08:21:31

tye wrote:

I’ve tested printing out the custom_field on the same form I am using this code and it works, but every time when I login with the user with the same privs, I get the error message:

There’s a bug in v0.11 that may be causing this. I’ll send you v0.12 in a bit. Got a few things to sort out first.

tye · 2012-07-31 22:59:43

No worries Stef, I know you’re busy :)

ecklesroad · 2012-10-17 16:39:04

I have a few privileges that seem to be “stuck” as in they are not in the smd_um_privs table but still show in the privileges tab and when I remove everyone from that item and save it does not get removed. Is this list cached somewhere?

Bloke · 2012-10-17 16:44:58

ecklesroad wrote:

I have a few privileges that seem to be “stuck” as in they are not in the smd_um_privs table but still show in the privileges tab and when I remove everyone from that item and save it does not get removed. Is this list cached somewhere?

In theory if they’re not in the DB they shouldn’t be there. However, sometimes the core’s settings (from admin_config.php) shine through, and this may be the case if you have set the privs to none: it may be a bug in my code if overriding core prefs results in this behaviour. Are they core events you are trying to override? I thought I’d handled the situation when you set them to ‘none’.

Also, plugin load order sometimes gets in the way (which is why smd_um runs nearly last).

What happens if you use the ® to reset them to default and then try again?

ecklesroad · 2012-10-17 18:13:48

Nope, it’s one I made custom, not one of the core privileges, so setting R does nothing.

There are two of them I’m trying to remove since they are not used anymore. Unchecking everyone from each and then saving does nothing, then I verified that they are not in the privs table. Then if I click save without unchecking those two custom ones they show up again in the privs table. Adding groups to those items works fine, but then trying remove all reverts to the initial value I had with was admin.

ecklesroad · 2012-10-22 16:21:34

I’m pulling my hair out on this one. I turned on TXP_DEBUG to see what was going on query wise. I can see the deletes of those two in question and there are no inserts after the delete, and I can confirm in the database that after the save those two are not in the privs table. Then also running the select area, GROUP_CONCAT(priv) AS privs from grtxp_smd_um_privs as smd_um_privs where 1=1 GROUP BY area ORDER BY area query which I assume is for grouping the privs for checkboxes, does not include either of these two items. But still they show up with admin checked.

There are several groups that I can not remove privs from, unchecking them and saving they just show up rechecked anyway. It’s not every group that I run into this which is the really weird part, it’s not consistent.

I should mention too this started happening when I moved the site from my localhost dev server on php 5.4 to our web server which is running php 5.3 on cPanel. Not sure why this would be an issue.

whaleen · 2012-11-16 08:49:40

On the bleeding edge with TXP v4.5.1 + smd_user_manager 0.11

Did a bulk delete of a large handful of users (added over the course of a year through several TXP upgrades) using smd_user_manager I had registered through mem_self_register. Housekeeping. Worked.

Funny thing is, all but a small handful of rows in the the txp_prefs table went missing immediately afterwards causing errors resulting from mostly no prefs.

All is well as I had a backup but wanted to report this oddity. I’m sorry I don’t have any more information. I honestly have no idea of what to say other than what I saw. Who knows what went down. Maybe someone has a guess as to what happened?

bici · 2012-11-18 18:26:09

I have given the group Staff Writer all privileges on the article (Article) tab: all options set to √

but a user that is logged in with Staff Writer prefs CANNOT seem to edit an existing article authored by the Publisher:

"Sorry, the form could not be submitted Please try again later."

I also set their privileges on the Form (Form) tab √

stumped

MattD · 2013-09-05 07:03:44

I’m using this plugin as well as smd_tabber. I can’t seem to get the permissions right so that a new group can get to a tab I added under “start”. I’ve checked the box next to dashboard and tab.start but nothing shows up for these users.

Note: I’m using the bleeding edge dev version of TXP because I needed some UI elements not yet available in the stable version. This might be part of the problem.

Last edited by MattD (2013-09-05 07:07:07)

Bloke · 2013-09-05 08:33:08

MattD wrote:

I’ve checked the box next to dashboard and tab.start but nothing shows up for these users.

Hmmm, the latest (“beta”) copy of smd_um should work on SVN just fine. Did you also add the new group to the View Privileges dropdown in Admin->Manage Tabs? The tabber plugin has its own settings which work alongside smd_um’s privs.

It’s an unfortunate side-effect of the fact that I wanted tabber to be able to mess with the built-in tabs privs so I added the ability to turn groups on and off directly in the plugin. For the built-in groups, that’s enough because Txp sets them “on” by default. But in smd_um you need to explicitly add the privs for the new group as an additional step. Sorry about the confusion.

If it’s not that, let me know and I’ll dig further.

Textpattern CMS

Textpattern CMS support forum

#49 2012-07-31 03:41:53

Re: smd_user_manager: keep large user bases under control

#50 2012-07-31 03:46:03

Re: smd_user_manager: keep large user bases under control

#51 2012-07-31 08:21:31

Re: smd_user_manager: keep large user bases under control

#52 2012-07-31 22:59:43

Re: smd_user_manager: keep large user bases under control

#53 2012-10-17 16:39:04

Re: smd_user_manager: keep large user bases under control

#54 2012-10-17 16:44:58

Re: smd_user_manager: keep large user bases under control

#55 2012-10-17 18:13:48

Re: smd_user_manager: keep large user bases under control

#56 2012-10-22 16:21:34

Re: smd_user_manager: keep large user bases under control

#57 2012-11-16 08:49:40

Re: smd_user_manager: keep large user bases under control

#58 2012-11-18 18:26:09

Re: smd_user_manager: keep large user bases under control

#59 2013-09-05 07:03:44

Re: smd_user_manager: keep large user bases under control

#60 2013-09-05 08:33:08

Re: smd_user_manager: keep large user bases under control

Board footer