Bug #3157
closedSubstitutions from user object as array returns null for gids and viewaccesslevel is missing as field-name
Description
When substituting a user object variable (gids) the result is null as it is an array. This happens because direct user object substitutions aren't processed into val1|*|val2. Proposed patch is to move the is_array check and processing directly after $val is obtained so it applies to field substitutions and user object substitutions.
Files
Updated by krileon almost 13 years ago
- File 3157.patch added
- File plugin.foundation.php plugin.foundation.php added
- Status changed from New to Resolved
- Assignee changed from krileon to beat
- % Done changed from 0 to 100
Updated by beat almost 13 years ago
- Status changed from Resolved to Assigned
- Assignee changed from beat to krileon
- % Done changed from 100 to 20
I don't like applying the array case on the fallbacks for old implementations.
Correct fix would be to fix the gid field-type to provide a proper getField() method ?
Updated by krileon almost 13 years ago
- Status changed from Assigned to Feedback
- Assignee changed from krileon to beat
gid doesn't exist as a field, it's a part of userparams so you can't use getField on it without basically adding a new system calculated field to CB that provides just gid. Regardless though user variables returning arrays still needs to be handled for the substitution usage; don't have any other solution to propose without having to completely add a new field.
Updated by beat almost 13 years ago
- Priority changed from High to Normal
- Target version set to CB 1.8
Actually, what would work much better is a specific IF on a View Access Level for the IF in substitutions. Testing on groups is nice too, but less useful.
Updated by krileon almost 13 years ago
I agree, I think both would be good to have though; could extend the IF parsing to have custom variables like accesslevel="2" or usergroups="6,8" (comma separated or |*| separated?). Would seam to be a pretty easy addition, but we still need gids to parse properly as it's kicking out an "Array".
Updated by beat almost 13 years ago
- Status changed from Feedback to Assigned
- Assignee changed from beat to krileon
Using groups directly is not the recommended way (except for assigning users to groups).
I would stick with viewaccesslevel="2"
Which is enough for all cases. It's easy to add access levels as required, and it's the standard way for viewing permissions.
For action permissions, you would need to use something like [IF authorize="action,asset"]. But:
1) Joomla doesn't yet have a way to define and manage user-defined assets and actions on them.
2) assets are mostly for backend for now
So groups and action authorizations should be postponed to after CB 2.0 imho.
For "viewaccesslevel" (trying to keep terminology) you are welcome to submit a patch.
For "gid" if you add a type at top of the cb.core.php file array, it can return a properly formatted, comma-separated string. But that is not required imho.
Updated by krileon almost 13 years ago
- File 3157_rev1.patch 3157_rev1.patch added
- Status changed from Assigned to Resolved
- Assignee changed from krileon to beat
- % Done changed from 20 to 100
Proposed patch just adds a check to see if the field is "viewaccesslevel" and if it is to parse the users view levels into |*| delimitered string. It could actually be moved further down as an ifelse to if ( isset( $user->_cbuser->$fieldLower ) ) {, but seams un-necessary to go through all that API first for viewaccesslevel.
Updated by beat almost 13 years ago
- Subject changed from Substitutions from user object as array returns null to Substitutions from user object as array returns null for gids and viewaccesslevel is missing as field-name
- Status changed from Resolved to Closed
- Estimated time set to 2:00 h
Fixed in r1752 .