I experience different notifications sent out, depending on the person TO whom the notification is sent. Tokens used in the notification templates have value or not, resulting to missing / different output.

For example I currently try to add information on uploaded files. Some users (the admin) receive an URL to that file, others don't. It's the very same post, different notifications sent out seem to go along with different rights.

E.g. the token subs:category:name is set for normal users but not for the admin. Instead the token subs:files:field_file:count is set for the admin but not for other users. I can't find any reason for this.

Some tokens in the user notification:
subs:category:tid = 59
subs:category:name = testing
subs:files:field_file:count =

And in the Admin notification (same post, sent out at the same time):
subs:category:tid =
subs:category:name =
subs:files:field_file:count = 1

It's a 7.16 installation with all modules up to date and no own patches.

Comments

salvis’s picture

Category: bug » support

[subs:category:*] is only set when the notification is triggered by a category subscription.

[subs:files:field_file:count] can be empty if the recipient user does not have access to the attached file(s).

Also, make sure that the notifications that you compare really are based on the same template. I've managed to get confused over this more than once...

Nigristriata’s picture

> [subs:category:*] is only set when the notification is triggered by a category subscription.
Ok, now I understand this one.

> [subs:files:field_file:count] can be empty if the recipient user does not have access to the attached file(s).
I'm using private files. The user has access to the files after logging in. But in the notification the link is not set. Does this mean that only public files can be used here?

salvis’s picture

Component: subscriptions_event » Code

It works fine with private files.

Make sure that "field_file" really is the name of your file field.

Also, consider upgrading to 1.1.

Nigristriata’s picture

After updating to 1.1 I tried again, but the problem stays the same.
The "field_file" is correct because the admin always receives a correct notification.
But everyone else doesn't receive this file information: [subs:files:field_file:count] and [subs:files:field_file:index:#0:url] are not set for everyone who's not an admin.

Are you sure you've tested the notification for a user without admin rights? But surely you did that. So I really don't know what's going on here. Should I go deep into PHP issues? I programmed with PHP a few years ago, but not with Drupal yet.

salvis’s picture

Version: 7.x-1.0 » 7.x-1.1

Yes, I'm sure. In fact, sending out nodes and comments (with links to attached files) from private forums is my main use of Subscriptions.

Should I go deep into PHP issues? I programmed with PHP a few years ago, but not with Drupal yet.

Yes, please — I'm out of ideas. You should be able to reproduce this issue in the Mail Editor Preview, if you have a user who has access to Mail Editor. You're saying it works only for administrators, but which permission exactly is required for the file links to work on your site?

Just to be sure: you have checked that your non-admins really do see the private files when they look at the node, right? Subscriptions checks the 'view uploaded files' permission before delivering the [subs:files:*] tokens.

What access control are you using?

Nigristriata’s picture

Great hint to use the Mail Editor Preview! First i gave the member the rights to use the Mail Editor Preview. Then I gave him all possible rights, nothing changed.
[subs:files:field_file:count] is not set and is displayed in the preview as "[subs:files:field_file:count]".

Then I searched the files and commented out the
if (user_access('view uploaded files'))
in line 96 of file subscriptions_content.tokens.inc and happily it works now. This helps me a lot!
In my drupal installation I don't need a distinction on different user rights concerning uploaded files.

What access control am I using? In the modules section the module "Content Access" is selected with version 7.x-1.2-beta1. Files have such an URL: http://[domain]/drupal/system/files/[file]. That's a virtual directory, they are stored in a special directory not accessible via http.

Thank you for your help! If I shall investigate more, I'll happy to do so.

salvis’s picture

There is a contradiction between "I gave him all possible rights, nothing changed" and the fact that not checking the 'view uploaded files' permission makes it work.

The only explanation is that user_access('view uploaded files') returned FALSE after all...

salvis’s picture

Status: Active » Fixed

Well, it turns out that this was a Subscriptions bug after all.

It's fixed in the new -dev version. See #1821116-6: Can't attach files for the full story.

I'm marking this support request as fixed. Please open new issues if needed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

trying to make the bug report better understandable