drupal_get_form('subscriptions_ui_node_form', $node, $account)

working version was

$Id: subscriptions_ui.module,v 1.12 2008/12/25 13:44:42 salvis Exp $

new version is (not working)

$Id: subscriptions_ui.module,v 1.16 2009/07/22 16:58:07 salvis Exp $

I compared the code in the 'subscriptions_ui_node_form' function in both versions and they are identical i believe??

Any help is appreciated.

Trevor

I reverted the line you referenced back to:

if (module_exists('comment') && $node->comment == COMMENT_NODE_READ_WRITE && user_access('access comments')) {

But the outcome is the same. The form still doesn't show unless I remove the $account param.

Sorry I thought the info I provided in #2 was what you needed. Is this what you need?:

version = "6.x-1.0-beta5"

My site is now sending notifications on "Blocked content types" to all users subscribed to a taxonomy term, when a new node is created with that taxonomy present even though it is on the "Blocked content types"

This is a HUGE issue for me. Again, I really appreciate your help.

Trevor

ok,

I created the other issue at:

http://drupal.org/node/611850

In the previous version of subscriptions I could call the subscription block for the author of a specific node by accessing the nodes uid and loading the $account then calling:

drupal_get_form('subscriptions_ui_node_form', $node, $account)

this line of code:

print drupal_get_form('subscriptions_ui_node_form', $node, $account)

is on page (contemplate page -but that doesn't matter and doesn't affect subscriptions) when that page is called the subscription form is presented with the subscriptions for the $account that is loaded.

_________________________________________________

If I read your function correctly it looks for the $account param and if it doesn't exist then it loads the subscriptions for the $user

This is the way it has worked on my site for almost a year.

now, with the latest version, the subscription form is not "print"ing to the page as it should, however if I remove the $account parameter and simple run:

print drupal_get_form('subscriptions_ui_node_form', $node)

then the subscriptions form is displayed as expected. If i again add the $account param then the form is not displayed.

_________________________________________________

I am not doing anything custom or strange with the module. I am simply calling the subscription form in a custom location via the function drupal_get_form

here is the complete working as expected version of subscriptions I had on my site. Niether this nor the http://drupal.org/node/611850 issues are present in the version. zip is attached

The only code changes i made were:

subscriptions.taxonomy.module;
********remove the words "to content in"

subscription.module;
$items['user/%user/subscriptions/'. $stype] = array(
'title' => $data['title'],
********'type' => MENU_CALLBACK,
'file' => 'subscriptions.admin.inc',
'page callback' => 'subscriptions_page',
'page arguments' => array(1, $stype),
'access callback' => '_subscriptions_access',
'access arguments' => array(1, $data['access']),
'weight' => (isset($data['weight']) ? $data['weight'] : 0),
);

here is the complete code for the page:

<?php 

global $user;
if (((in_array("Investor Administrator", $user->roles)) || ($node->field_user_reference['0']['uid'] == $user->uid) || ($node->uid == $user->uid)) && ($user->uid != 0)){
$account = user_load($node->uid);
?>

<div id="case">

<?php
if (in_array("Investor Administrator", $user->roles) || ($node->field_user_reference['0']['uid'] == $user->uid)){
?>

<fieldset class="collapsible collapsed">
<legend>Edit Information</legend>
<div>

<?php
module_load_include('inc', 'node', 'node.pages');
print drupal_get_form('investment_node_form', $node);
?>

</div>
</fieldset>

<?php
}
?>

<div id="company_chart">

<?php 
if ((in_array("Investor Administrator", $user->roles)) || ($node->field_user_reference['0']['uid'] == $user->uid)){ 
?>

<ul class="contact_info">
<li>Name: <?php print $account->realname;?></li>
<li>Phone: <?php print $account->profile_phone;?></li>
<li>Email: <a href="mailto:"><?php print $account->mail;?></a></li>
<li>Home Phone: <?php print $account->profile_home_phone;?></li>
<li>Work Phone: <?php print $account->profile_work_phone;?></li>
<li>Cell Phone: <?php print $account->profile_cell_phone;?></li>
<li>Fax  Phone: <?php print $account->profile_fax;?></li>
</ul>


<div class="case_blue"></div>

<?php
//print_r($account);
}
?>



<div id="case_links">

<?php
if ((in_array("Investor Administrator", $user->roles)) || ($node->uid == $user->uid)){
print drupal_get_form('subscriptions_ui_node_form', $node, $account);
}
?>


</div>
</div>


<?php
if (in_array("Investor Administrator", $user->roles) || ($node->uid == $user->uid)){
?>

<fieldset>
<legend>Investment List</legend>

<?php
$view = views_get_view('other_investments');
print $view->preview('page_1', array($node->uid));
?>

</fieldset>
<?php
}
?>

<?php print $node->body ?>

<div id="clear_both"></div>
</div>

<?php
}
?>

everything works except the subscriptions form. The subscriptions form worked Since last DEC, until i upgraded the module. This code has not changed.

was there a db update in the latest version I installed, or can I simply roll it back? again this appears to be a subscriptions issue since that is the only thing that changed.

this is not custom php code this is very basic function calling.

I swapped out the subscriptions module for the previous version (attached in comment #12) and everything works as expected. The issue appears to be in the new release of the module.

For now I will use the older version.

Both the "blocked content types" and the ui_form behave per the module comments in that version.

ok,

After way too much time I took another crack at this and have determined the issue to be "Permissions"

In previous versions of the subscriptions module I could call the subscription form via:

print drupal_get_form('subscriptions_ui_node_form', $node, $account);

and I could do this successfully on any content types, even if those content types were "Blocked content types" in the subscription admin settings. I only use subscriptions with taxonomy terms so it didn't matter where I called the form. Only the taxonomy terms would show up as possible subscription options.

The latest versions of Subscriptions have tightened the blocked content settings to the point, that I can't call the subscription form on a blocked content type even if it has taxonomy that I need to be able to access, unless I grant all the subscription permissions.

If i allow subscribe to all content types for my users then the form will display on the blocked content type with the option to subscribe to that content type which is obviously not what I want.

So, is there a way to still display the subscription form on a page where the content type is blocked but the taxonomy terms on the page are still subscribable?

-Trevor

the issue is the following:

I have content types that can trigger subscription notifications, but I also have content types that are categorized by taxonomy that includes terms that could trigger subscription notifications.

example: I track legal cases on my website and users can subscribe to the "Case"(content type) taxonomy term name of the Company(taxonomy) mentioned in the "Case". I also have a content type called "Investment" that users can create so that they can tell us about their involvement in the Case(content type). the correlation between these two is made via the common Company(taxonomy). In this example, I need cases to trigger subscription notifications and "Investments" to not, but i would like the ability to manage their subscriptions to the terms from either content type since they are taxonomy based and not content types.

It seems to me that we could add a permission set like the "Blocked content types" that currently exist for the subscription types, but we could do it specifically for the UI_form for subscribing or unsubscribing. This is a simple solution that imho would add a lot of flexibility to developers. What do you think?

-Tervor

ok, sorry if i was unclear let me try again.

there are two content types: "Case" and "Investment"

they both share a cck taxonomy field called "Company Name". "Case"(s) trigger subscriptions based on "Company Name" taxonomy, "Investment"(s) do not.

For the "Case" content type the taxonomy "Company Name" is used to categorized the company that the case belongs to. And for the "Investment" content type the taxonomy "Company Name" is used to categorize the company that was invested in.

The site structure:

Admin or authors can create "Case" content types and assign the "Company Name" taxonomy and publish it to the site so it is searchable(by taxonomy). example - "Case" created with the case details and "IBM" as the "Company Name" taxonomy field.

Site Visitors can browse the "Case"(s) and if they have invested in the "Company Name" then the can create an "Investment" content type that they would be assigned the same "Company Name" and publish it to the site ***but only for Admin to see**** "Investment" content types are only used as a form to gather and organize user information for site admin's, this information is not accesible to any other users and should never trigger a subscription to be sent . example - a visitor is browsing the "Case" (s) and finds a case for IBM, the user can send us the details of his investment in IBM by creating an "Investment" node that is assigned IBM as the "Company Name".

An Investor in IBM should be able to subscribe to any future "Case"(s) or updates to "Case"(s) that contain the IBM taxonomy term for the "Company Name" and they should be able to subscribe to the IBM Taxonomy term whether they are looking at the "Case" for IBM or the "Investment" for IBM that they created.

Even though "Investment" content types won't trigger subscriptions being sent, they still contain the taxonomy terms that will trigger subscription notifications for the "Allowed content types" By separating the permission for the subscription ui form from the permissions for the Blocked content types I could still prohibit a subscription notification from being generated when a new visitor creates and IBM "Investment" and I could allow that visitor to subscribe to the IBM taxonomy term for future "Case" content or updates, right there on his "Investment" node he just created.

Does that make sense?

-Trevor

Aren't you using some kind of node access protection to keep the
Investments secret? Subscriptions is node access-aware and that same
mechanism should keep it from sending notifications about Investments to
any client besides the owner. I don't think you need to block the
Investments content type at all.

No, I had to write custom PHP into the tpl.php for the "Investment" content type to control access to the content since I needed specific admins to be able to see specific investments based on a cck reference field. Basically, when an "Investment " is submitted for review, a "investor administrator"(role) reviews the information then assigns it to one of many "investor managers" (role). the only investments that the "investor managers" can see are the ones that are assigned to him. In order to make that happen I had to write custom code in the tpl.php.

Also, you can turn off sending of notifications for the Investments
content type on the content type admin page (this is a new feature in
the -dev version) and only users with the 'administer nodes' permission
will be able to change that (temporarily).

This might work for now, but I still think separating out the permissions for the allowed content and the subscription form will give the module even more depth.

By the way.... I love the module thank you so much for all your hard work...

I will try your suggestion and report back.

-Trevor

I tried the new dev.

I removed the "Investment" node type from the "Blocked content types" in the admin settings and I disabled all the subscription triggers in the content type settings.

The form displayed on the "Investment" node but even though all the triggers were removed from the content type the form still asks if I want to subscribe to Investment content, which is what I don't want.

I can go in and manipulate the ui in the module to remove any content type options from being returned to the form as a hack fix for now, but do you see the potential for splitting the permissions?

what do you think?

-Trevor

here is a picture of the subscription form:

here are the mods that I make each time I install the subscriptions module. the third one was just added to address the issue we are discussing in this thread. I am not sure if this is helpful to you or not.....

subscription mods

1. - subscriptions.taxonomy.module;
remove - "to content in"

2. - subscription.module;
change MENU_LOCAL_TASK item MENU_CALLBACK:

$items['user/%user/subscriptions/'. $stype] = array(
'title' => $data['title'],
'type' => MENU_CALLBACK,
'file' => 'subscriptions.admin.inc',
'page callback' => 'subscriptions_page',
'page arguments' => array(1, $stype),
'access callback' => '_subscriptions_access',
'access arguments' => array(1, $data['access']),
'weight' => (isset($data['weight']) ? $data['weight'] : 0),
)

3. - subscriptions.content.module
comment out the following lines:

// Content type
$type_name = check_plain(node_get_types('name', $node->type));
//if ($type_name) {
//$options['type'][] = array(
//'name' => t('To %type content', array('%type' => $type_name)) . $unlisted_tag,
//'params' => array('module' => 'node', 'field' => 'type', 'value' => $node->type),
//'link' => 'type/'. $node->type,
//);
//// Content type and author
//$options['type'][] = array(
//'name' => t('To %type content by %name', array('%type' => $type_name, '%name' => ($node->uid ? check_plain($node->name) : variable_get('anonymous', '???')))) . $unlisted_tag,
//'params' => array('module' => 'node', 'field' => 'type', 'value' => $node->type, 'author_uid' => $node->uid),
//'link' => 'type/'. $node->type .'/'. $node->uid,
//);
//$options['type']['weight'] = -2;
//}
}
return $options;

-Trevor

Have you tried removing the 'subscribe to content types' permission?
That ought to take care of (3), too.

In the latest dev version of the module 'subscribe to content types' isn't a permissions option anymore.

- I am fine with tweaking the module the changes are very minor.

****I am having an issue with updated content not triggering notifications as it should. When I create a new "Case" with the "Company Name" assigned, the subscriptions are sent out as they should. however if I update the "Case" (i make sure that the 'send subscription notifications' check-box is selected in the node 'publishing options') nothing is sent to the subscriptions_queue table and of course then no notifications are sent for the updates.

Should I log a new Issue in the queue? what do you think******

here is a picture of the permissions for subscriptions

What do you mean by "the unpatched 6.x-1.x-dev"

-Trevor

this is from subscriptions.module

/**
 * Implementation of hook_perms().
 *
 * @ingroup hooks
 */
function subscriptions_perm() {
  return array_merge(array('administer user subscriptions', 'subscribe to all content types'), subscriptions_types('access'));
  t('administer user subscriptions');
  t('subscribe to all content types');
}

-Trevor

Ok the fresh install and cache clear resolved the permissions issue.

Unfortunately the updated content is still not triggering notifications so I will enter that issue in the queue. I think this issue is as resolved as it is going to get. Thanks for all your help.

Here were my final changes for anyone interested:

1. - subscriptions.taxonomy.module;
remove - "to content in" for aesthetics and site needs

2. - subscription.module;
change MENU 'type' to MENU_CALLBACK so we can use our own link to the subscriptions/taxa page and not worry about this one showing up:

$items['user/%user/subscriptions/'. $stype] = array(
'title' => $data['title'],
'type' => MENU_CALLBACK,
'file' => 'subscriptions.admin.inc',
'page callback' => 'subscriptions_page',
'page arguments' => array(1, $stype),
'access callback' => '_subscriptions_access',
'access arguments' => array(1, $data['access']),
'weight' => (isset($data['weight']) ? $data['weight'] : 0),
)

3. - subscriptions.content.module
Change the following 'access' types sot that users do not have access to these pages

function _subscriptions_content_types() {
$tr = 't';
$types['node'] = array(
'title' => 'Pages/Threads',
'access' => 'administer user subscriptions',
'page' => 'subscriptions_content_page_node',
'fields' => array('node', 'nid'),
'weight' => -4,
);
$types['type'] = array(
'title' => 'Content types',
'access' => 'administer user subscriptions',
'page' => 'subscriptions_content_page_type',
'fields' => array('node', 'type'),
'weight' => -2,
);
return $types