Problem with auto-newsletter and CB Query fields

Hi Guys

Acyba has been very kind in developing a new plugin for extracting data to newsletters via the CB API instead of going straight to the DB.
It works if you manually generate the newsletter, and send it out.

The problem arises with the auto-newsletter. The auto-newsletter is sent out via a CRON script, and when that is done, there is no authorization applied on the frontend.
If the TAB where the field is present has an ACL where public is not allowed access to it, the plugin fails to retreive the values.

They've suggested a change in the CB code to allow newsletters to fetch values:

Anyway, a quick fix for you would be to edit the CB file "administrator/components/com_profiler/comprofiler.class.php" on line 3804.
Replace:

Code:

if ( $reason != 'register' ) { $where[] = 't.useraccessgroupid IN (' . implode(',',getChildGIDS(userGID( $_CB_framework->myId() ))) . ')';

}
By:

Code:

if ( $reason != 'register' && empty($fieldIdOrName)) { $where[] = 't.useraccessgroupid IN (' . implode(',',getChildGIDS(userGID( $_CB_framework->myId() ))) . ')'; }

I don't have enough knowledge on CB code to guarantee you it's not gonna have a negative impact on other parts of CB (I don't think so but...)

Now about the long term fix, I would be happy if you could ask the CB team... Maybe they will apply directly this fix on the next CB release if they also think that getting a field by its ID should not add any ACL check. Or they may have an other solution...

But as they also say, if the CB team has a better way to solve this, they are all ears

They've suggested a change in the CB code to allow newsletters to fetch values:

Never make core edits. It voids your support and we can no longer help you. In addition to that the change breaks the entire retrieval of fields. It's import that the API respects permissions.

if they also think that getting a field by its ID should not add any ACL check.

Don't agree; it's designed to support either/or and depending on the situation only 1 or the other maybe available without having to do a DB query to retrieve the other.

Or they may have an other solution...

Where he's using getField he can specify a reason of "register", "adminfulllist", or set the $fullaccess variable to true. Example as follows.

Register Reason:
Admin Reason:
Full Access:
Ideally it's best to just pass content through $cbUser->replaceUserVars( $CONTENT ) and use substitutions inside of your content as you can then specify whatever reason, etc.. you want wherever it's needed.

Ok, I sent your reply to Acyba, and he's tumbling with the issue, this is the first result:

Where he's using getField he can specify a reason of "register", "adminfulllist", or set the $fullaccess variable to true.

This is indeed what I was talking about with the "reason : register" but...

$myfield = $cbUser->getField( $fieldIdorName, null, 'html', 'none', 'register' )

This one will remove the ACL verification but will add a "f.registration = 1" which I guess means the field should be configured to be displayed on the registration page, which won't be the case.

$myfield = $cbUser->getField( $fieldIdOrName, null, 'html', 'none', 'adminfulllist' )

This one won't remove the ACL when we load the field

$myfield = $cbUser->getField( $fieldIdOrName, null, 'html', 'none', 'profile', 0, true )

Same thing for this one, it does not change anything.

Ideally it's best to just pass content through $cbUser->replaceUserVars( $CONTENT ) and use substitutions inside of your content as you can then specify whatever reason, etc.. you want wherever it's needed.

I'm all ready to use whatever function is adapted... I'm gonna have a look at it tomorrow.

As I'm not a coder, I can understand what is being said, but I can't help

Hmm, was the below API usage properly tested? Seams to be working fine for me.

The last variable (true) sets it to ignore access permissions. This won't exclude CB Conditional, CBSubs, or CB Privacy hidden fields though as they're based off a trigger.

If he wants to ignore all forms of access/privacy controls then probably is best to use direct database queries or direct user object variables as found in $user (e.g. $user->name) of a cb user.

The whole issue is that it's a CB query field, so database lookups does not work.
And there can be privacy set for the fields as well.
I can turn off privacy for one of the tabs I guess, but the privacy is set for the other, and as default (with auto-trigger) set to private.
So I guess there are both ACL and privacy involved (thought they used the same system).

Hmm, I just had an idea, from the other thread we're talking in.

Can I create a delimiter field on a tab without privacy settings and then just use the field substitution for the field with the privacy set?

Ie.

TAB: Residence (privacy set)
FIELD: cb_postnrby, CB Query field, value is a sql query

TAB: Status (no privacy options available for the user)
FIELD: cb_acyby, Delimiter field, field not shown on profile, value is [cb_postnrby].