Help using a User Extended Field as value for tree_root_id in User Groups

Hi All,

I have a user group that is setup and works fine. It's using the tree_root_id setting to limit a user to a root folder. This works great when a Resource ID is used as the value, ie. 220 (or whatever). What I'd ultimately like to do though is use a user's extended field, we'll call it "treeid", to set this value instead.

I've gotten to the point where I can show the extended field value on the front-end with the following "getUserExtendedField" snippet:


and for reference


but plugging that reference bit into the value field for the tree_root_id doesn't work.

For giggles I also tried:


using something similar for TV values seemed to work on a another project, but no luck here...

Any tips? Thanks!

I think what you want is a user setting (on the settings tab when editing the user).

Create a new setting called tree_root_id with your desired value for that user.

MODX will use it instead of the System Setting just for that user.

Quote from: BobRay at Dec 07, 2016, 04:47 PM

I think what you want is a user setting (on the settings tab when editing the user).

Create a new setting called tree_root_id with your desired value for that user.

MODX will use it instead of the System Setting just for that user.

Funny you mention that, I actually found that right after I posted this... BUT a weird issue kept happening. I'd set the tree_root_id of a user in the settings and save, but every time that setting would be applied to a different user account. I had not previously setup a tree_root_id for any other user, but they just kept popping up when I edited my target user. Any idea what might be happening there?

That's really weird. You might try repairing the modx_users and modx_user_settings tables in the DB.

You're creating the settings in the Manager, not in code, right?

I wouldn't know where to start repairing a table, I'm just the frontend guy

Yes, I was editing the user in the manager. Edit user 77 and 43 would change... the weirdest thing!

I've never seen anything like that.

Do you don't have any plugins that might be connected to a user save event (i.e., any plugins that do anything related to user management)?

Are you using ClassExtender or extending the modUser object?


Repairing tables is actually pretty simple, assuming that you have cPanel and login credentials for it.

1. In cPanel, launch PhpMyAdmin (in the database section)
   [li>You may need your database credentials for PhpMyAdmin. Look in the core/config/config.inc.php if you forgt them.
2. In PhpMyAdmin, select the MODX database on the left (you should see all the MODX database tables on the right)
3. Scroll down to the bottom of the table list and select the "Check All" checkbox
4. To the right of the "Check All" checkbox, use the "With Selected" drop-down and select "Repair Table

That's it.

Just out of curiosity, while you're there, select the modx_users table in the list. Compare the values in the 'id' and 'internalKey' fields. See if there is a mismatch that matches the error you're getting -- e.g., user with ID 77 has an internalKey of 43 or vice versa.

Mismatches between the 'id' and 'internalKey' fields, per se, are *not* a problem. In fact they are normal, but if some plugin that messes with users is assuming that they're always the same, it could cause your problem.

Did your own code ever save a user or user profile? If so, you might have altered the stored keys (repairing the tables won't help with this).

Here's how it's supposed to work (and you can check in the DB to see if it's set up this way):

• The basic user information is in the modx_users table.
  
• The user profile is in the modx_user_attributes table.
• In the modx_user_attributes table, the internalKey field for a row holds the ID of the user whose profile is stored in that row.
  
• IOW, the 'id' of the user in the modx_users table should match the internalKey file of the line for that user's profile in the modx_user_attributes table.
  
• In the modx_user_attributes table, the 'id' field is meaningless with respect to users. It often matches the 'internalKey' field, but it definitely doesn't have to.
  
  

[ed. note: BobRay last edited this post 9 years, 9 months ago.]