Yes, but the field might be removed elsewhere in the field API chain by conditions. I don't understand why you're conditioning something you need accessible to technically a user that should not have access to it.
Move the field to a tab in a not shown on profile position. Next remove all conditions against it. Now create a Custom HTML field that substitutes the field in. Then add your conditions to the Custom HTML field. This separates the rendering on profile from the field itself. It can now be used externally safely regardless of how the Custom HTML field renders it on profile. Example as follows.
cb_refid = query field, no conditions, on tab in not shown on profile position
cb_refid_display = custom html field, substitutes in cb_refid, has conditions and any other access checks needed on it, used for display on profile/userlist
Having this separation will prevent any and all access problems. Custom HTML and Query fields have no _comprofiler column storage so you can quite literally have unlimited amounts of them without performance or storage concerns so feel free to do this with any fields that need dual access behaviors.
With CB 3.0 will look into an explicit API access for fields that makes more sense to try and bypass any checks. The alternative is trying to use the PHP output to bypass checks. Example as follows.
Code:
$value = $user->getField( 'cb_refid', null, 'php', 'none', 'profile', 0, true );
if ( is_array( $value ) ) {
$value = array_shift( $value );
if ( is_array( $value ) ) {
$value = implode( '|*|', $value );
}
}
This is the same as doing [FIELD_NAME] to get raw values except it works with non-stored fields.
krileon
