Hello,

I wasn't able to find if this topic has been brought up before, so maybe there isn't much desire for it but it seems to me that as an admin when you set all users to autosubscribe by default then each user should not have to update their preferences to make it so.

As it is, with autosubscribe by default set in admin >> settings >> subscriptions the user looking at their profile settings will see the autosubscribe checkbox checked, which would lead them to think that they will be subscribed to content they create. However, if they have never clicked to save their profile then the autosubscription is not entered into user table so in truth they are not subscribed to new content.

My feature request is that when the admin sets autosubscribe by default for any user, who does not already have subscriptions_auto in the data field of the users table set, that they will in fact be autosubscribed and will not need to save their profile.

Is this possible? Was there a specific reason why this was not done in the first place? I have tried to use the load case of subscriptions_user() to run a user_save() but so far it is not proving successful.

Any and all input will be appreciated, thanks.

Comments

coltrane’s picture

I made a workaround so that users are at least actually autosubscribed, but I still request that this issue receive further attention.

In subscriptions_autosubscribe() to check if subscriptions_auto is NOT set. If it is not set then it means the user has not explicitly chosen to not be autosubscribed to content, then default to what I as an administrator have set, which is is to be autosubscribed.

I made this addition after the if ($user->subscriptions_auto) {...} in subscriptions_autosubscribe():

if (!isset($user->subscriptions_auto)) {
    // check to see if already subscribed
    $result = db_query('SELECT sid FROM {subscriptions} WHERE sid = %d AND 
stype = \'node\' AND uid = %d', $nid, $uid);
    if (!db_num_rows($result)) {
      // if not, subscribe
      subscriptions_add($nid, $uid, 'node');
    }
}
dkg’s picture

Status: Active » Needs review
StatusFileSize
new3.29 KB

I agree that this would be a useful feature.

I'm attaching a patch (against subscriptions 4.7.x-1.2) which seems to enable the right functionality for me, and modifies the documentation to reflect the change.

I'd be happy to see this fix get merged in upstream.

dkg’s picture

There was also discussion about this in issue 73915, which i've just closed as a duplicate of this one.

coltrane’s picture

Version: 4.7.x-1.x-dev » 5.x-1.9
StatusFileSize
new2.24 KB

I've rerolled dkg's patch for subscriptions 5.x-1.9. I'd offer a patch for the new 5.x-2 branch but it feels pretty unsettled at the moment.

salvis’s picture

This is a valuable issue, but I believe there won't be much committing in the 5.x-1.x branch anymore. The action is now in the 5.x-2.x-dev branch, but it's still work in progress, so you wouldn't want to install that version on a production site just yet.

But, please, submit the patch for 5.x-2.x when the dust has settled, which should be pretty soon now.

P.S. You might want to remove yet another comma after "This essentially"...

salvis’s picture

Version: 5.x-1.9 » 5.x-2.0-beta6
Status: Needs review » Fixed

This is fixed in 2.0. If a user hasn't saved (or reset) their preferences, then the site defaults are used.

Anonymous’s picture

Status: Fixed » Closed (fixed)

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