>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #520118. --> Reported by: [David Goode](https://www.drupal.org/user/291318) >>> <p>og_notifications still creates its own variable, og_notifications_content_types, to store settings on whether to be enabled for each content type. To complicate matters, it doesn't check this when creating links to create subscriptions, and notifications access doesn't do a per-content-type check for this type of thing, so disallowed grouptype subscriptions can be created... This patch fixes that, gets rid of this extraneous code and brings it back up to notifications spec. I've only lightly tested it so far pending the following issues which we need some closure on to make this viable for use on the relevant projects:</p> <p>Namely, what is going on with og_notifications feature regression in recent patches? Per-subscription type admin pages are still used in other notifications modules on the user account pages--why did a recent patch get rid of them for og_notifications? <a href="http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/og/modules/og_notifications/og_notifications.module?r1=1.24.4.9&amp;r2=1.24.4.10">http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/og/modules/og_notifications/og_notifications.module?r1=1.24.4.9&amp;r2=1.24.4.10</a></p> <p>Also, what was the reasoning behind getting rid of group-wide subscriptions in the same commit? <a href="http://drupal.org/node/432476">http://drupal.org/node/432476</a> doesn't explain much.</p> <p>Both of these things might be useful on some of our projects, many of which still use OG 1.3 largely for these reasons, and I was thinking of cleaning up and upgrading these functionalities to the latest notifications 2 API and re-adding them unless there's some reason against doing so?</p> <p>Thanks,<br> David</p>