smd_user_manager: keep large user bases under control

MattD · 2013-09-05 15:56:16

Installing the beta version seems to have solved it. ~~Is there a trick to reseting sdm_faux_role if i’ve accidently remove the permission for the role I am faux as to not be allowed to get to the role switcher?~~ PhpMyAdmin to the rescue.

Last edited by MattD (2013-09-06 03:19:29)

MattD · 2013-09-06 04:50:33

I have another issue (or two).

Workaround found for this issue
I created a new user group, assigned a new user to the group. Then I have the following in a smd_tabber tab.

<txp:smd_um_has_privs group="7">
<!--coach-->
<txp:output_form form="coach_dashboard"/>
<txp:else/>
<!--admin-->
<txp:output_form form="admin_dashboard" />
</txp:smd_um_has_privs>

When logged in as the user I get the admin version when I expect coach, I found a work around of using <txp:smd_um_has_privs group=">6">.

Second Issue

I am also using smd_bio, I added a bio item but saving a value via smd_user_manager doesn’t get it into the smd_bio table.

Thanks for any help you can provide.

Last edited by MattD (2013-09-06 04:55:24)

Bloke · 2013-09-06 09:22:11

MattD wrote:

When logged in as the user I get the admin version when I expect coach, I found a work around of using <txp:smd_um_has_privs group=">6">.

Very strange. I copied and pasted your version with group="7 into my smd_tabber dashboard tab, set up a group 7, gave the group Dashboard and Start.Tab privs via smd_um, added the group to the smd_tabber privs for the dashboard tab, added a user to the group, switched browser, logged in as the new Group 7 user and the first thing that popped up was the level 7 dashboard. My admin user saw the admin dashboard. I’m running bleeding edge SVN, too.

Can’t figure why it isn’t working for you. Is smd_user_manager running fairly late in the load order? Mine’s at level 8 which seems to be about right for most applications. I even toggled the smd_um setting for Assume hierarchical groups to see if maybe it made a difference, but it doesn’t. Baffling. Maybe a rogue PHP issue. What version are you running? I’m using 5.3.9 at the moment.

Try adding debug="1" to your smd_um_has_privs tag. You’ll get a splurge of output. First thing is the logged-in user array, so check that corresponds with the info you expect for the current user. Then you’ll likely get two NULL values because the permission and group areas are only cached after the first use of the tag. Then you’ll get three arrays that correspond to the attributes you’ve supplied to the tag.

Next are three rows that indicate which of the three tests (name, group, area) passed or failed. An empty entry is fail/not tested, a 1 means it passed the check. In your case, only testing group, you should get blank, 1, blank, but it sounds as if you’ll see three blanks here for some reason. Finally, you’ll get a value in all capitals which indicates the action the plugin took. It should say CHECK GROUP for your case, because that’s what it’s doing: checking the group against the privs value in the logged-in user array that was dumped to the top of the screen.

Maybe something in that debug info will help narrow down what’s going on as you twiddle with the attributes / accounts / privs.

I added a bio item but saving a value via smd_user_manager doesn’t get it into the smd_bio table.

Are you using the beta? I tried saving a bog standard text field on my server and it stored it. Which field type is it you’re trying to save? If you let me know its definition I can try the same one on my install and check I haven’t messed something up.

Also, if you have phpMyAdmin handy, check the table definitions for smd_bio and smd_bio_meta. Make sure the definitions tie up with how you set them up, and that the collations on the columns match the collations in other tables (such as the textpattern table). The latest beta is supposed to fix any discrepancies, because the older version didn’t set the collation properly, but maybe it hasn’t done it for some reason and you’ll need to fix them manually. The upgrade process also changes the position column from int to varchar.

If the collations or table defs aren’t right under the beta smd_bio, then I’d like to know your MySQL/PHP versions please, in case it’s something I need to address. Also, have you assigned ALL PRIVILEGES to the MySQL user? smd_bio uses SHOW TABLE STATUS and also tries to extract information from the INFORMATION_SCHEMA.COLUMNS field. Some people have complained that testing this field produces errors so I’ve (naughtily) suppressed output as a temporary measure until I can find a better way of checking the column type.

Sorry for the hassle this has caused. Thought I’d fixed all this, but with your help I’ll be able to track down any remaining issues and fix them. Thanks.

MattD · 2013-09-06 16:08:02

I updated to the beta version of smd_bio and that resolved the issue with my profile field not persisting. I’ll try and do more research into the other issue when I have time but since it’s working with the >6 and I currently don’t have other levels I need to support I’ll be moving forward with this solution.

Thanks for the help and great plugins Stef! When I get paid for this site I’ll send you a beer of 4.

EDIT : Strangely enough its not working with =7 as well.

Last edited by MattD (2013-09-06 16:12:52)

MattD · 2013-09-14 00:02:18

Can I prevent a user from editing smd_bio fields of their own record?

Bloke · 2013-09-14 08:22:09

MattD wrote:

Can I prevent a user from editing smd_bio fields of their own record?

Sadly I don’t think that’s possible at the moment. I’d have to check the smd_bio code but I think the privs are just “are you the owner?” and if so, you can edit them. Some concept of read-only fields and/or a priv group for smd_bio.read-only is a neat idea.

At the risk of decorating this thread with smd_bio questionage, can I just ask what your intended use is for read-only fields? Would it be handy to be able to designate that certain fields were editable only by a given privileged user group (on the Admin->Users panel) when the fields are defined? The implementation of editable fields on the public side using the widget attribute is of course up to your application, so I would do no such enforcement on that front. But the plugin could maybe help out by offering a way to test for ‘is privileged’ in the <txp:smd_if_bio> tag.

I’d have to look into what was possible and what made most sense from a usability and functionality point of view. Any ideas on either front, throw them my way and I’ll see what I can do.

MattD · 2013-09-14 15:01:57

I need the admin to assign a value to the user when they create the user. I don’t want the user to be able to edit that value. If my usecase is unusual I can probably hack something together. I already am to populate a smd_bio select with values from a list of articles.

Sorry about crossing plugin threads. Let me know if we should carry on somewhere else.

Destry · 2013-09-21 08:22:15

Stef,

On a Txp 4.5.4 install I updated smd_bio from v. 0.20 to 0.40. No problems. I then installed smd_user_manager (UM) .20. Two things happened:

All the plugin’s UI labels are in code-ese, for example.
After creating some new bio fields (e.g., select, multi-select…), the values for custom bio fields that already existed turned to “0000-000-00*, or something like that. A lot of zeros and dashes, which appeared both in context of editing a user’s data, and in the front end output. If I tried to correct the fields by replacing the zeros with correct data, it would revert back to zeros on save.

In the latter case, I deleted the corrupted bio records and recreated them. (Thankfully not a lot of users yet so it was a small ordeal.) After recreating the fields they worked fine.

The other thing I notice, but maybe this is normal and I just never paid attention before, is that when I’m in the Plugins panel, I don’t see the UM option in the Admin menu (just Users), and the Extension tab doesn’t appear in the main menu either. This is kind of awkward when you’re using the menu to navigate the admin-side. Shouldn’t it be consistent across the views?

I’m mainly just bringing this to your attention, but I still have the problem with #1. How might I fix that?

maverick · 2013-09-21 14:17:34

Destry wrote:

The other thing I notice, but maybe this is normal and I just never paid attention before, is that when I’m in the Plugins panel, I don’t see the UM option in the Admin menu (just Users), and the Extension tab doesn’t appear in the main menu either. This is kind of awkward when you’re using the menu to navigate the admin-side. Shouldn’t it be consistent across the views?

Destry – all plugins are disabled when in the plugin panel. It’s a security feature in case of a malicious or runaway plugin. Consequently any menu links for a plugin also disappears as well across all tabs.

Destry · 2013-09-21 14:50:39

Thanks for the confirmation, Mike. I thought that might be normal.

Destry · 2013-09-25 15:10:50

Destry wrote:

All the plugin’s UI labels are in code-ese, for example.

Fixed. Turned out to be a missing textpack.

THE BLUE DRAGON · 2013-10-05 08:40:55

Destry wrote:

Fixed. Turned out to be a missing textpack.

How did you fixed it please? where do I get that textpack from please?

Textpattern CMS

Textpattern CMS support forum

#61 2013-09-05 15:56:16

Re: smd_user_manager: keep large user bases under control

#62 2013-09-06 04:50:33

Re: smd_user_manager: keep large user bases under control

#63 2013-09-06 09:22:11

Re: smd_user_manager: keep large user bases under control

#64 2013-09-06 16:08:02

Re: smd_user_manager: keep large user bases under control

#65 2013-09-14 00:02:18

Re: smd_user_manager: keep large user bases under control

#66 2013-09-14 08:22:09

Re: smd_user_manager: keep large user bases under control

#67 2013-09-14 15:01:57

Re: smd_user_manager: keep large user bases under control

#68 2013-09-21 08:22:15

Re: smd_user_manager: keep large user bases under control

#69 2013-09-21 14:17:34

Re: smd_user_manager: keep large user bases under control

#70 2013-09-21 14:50:39

Re: smd_user_manager: keep large user bases under control

#71 2013-09-25 15:10:50

Re: smd_user_manager: keep large user bases under control

#72 2013-10-05 08:40:55

Re: smd_user_manager: keep large user bases under control

Board footer