OG Notifications does not display the Content type in group link in the user profile

@Zen - any thoughts?

#2 Patch doesn't work for me (running 6.x-2.x-dev)
I would like to get this working as there doesn't seem to be a way for my users to control group subscriptions since it was removed in RC2.

I have patched #5 into a vanilla installation on a test machine with only the required modules needed to test this feature. Flushed the caches. Double-checked the configuration of notifications and types, etc.

This doesn't seem to display the "Content type in Group" tab, but rather it brings back the "Groups" tab, under the profile Notification section.

Also, It looks like this patch sets the 'access callback' => FALSE for the "Content type in Group" menu, which hides it (as I understand it). (I think this was the original setting in RC1)

The main concern with this patch is it seems to bring back the "Groups" tab feature that was removed in RC2 for some reason: ?#443810: Autosubscription to group post upon joining the group always create subscriptions to Group content types
Actually, I prefer the old "Groups" tab approach because it is intuitive for the users (and it can always be disabled, if not wanted)- not sure why it was removed.

The old "groups" tab approach was shelved (but backported to D5) due to notifications pursuing a unified admin UI.

@Darren: Could you please remove the cruft from the patch (.info etc.) and break it up into review-able pieces? Perhaps get hook_notifications sorted (and consequently "add subscription") with one patch, the UI with another.

I'd also like to hear your opinions on the duplicate UI that will ensue (and is now already present) if the UI patch is readded in.

Does an UI exist for something like this? I haven't seen it unless you are talking about the "subscriptions" tab or similar. I have been using og_notifications for a while and our users really like the simplicity of managing the groups with it (the pre RC2 model). (And we love the new features to cancel all subscriptions - great for CAN-SPAM ACT)

I have a client who is interested in seeing this fixed, and I'm wondering how to best help with this issue.

Based on the discussion in this issue and a bit at #520118: Compatibility with Notifications 2 per-content_type settings and re-adding two features I've come to understand that

- og_notifications.module's hook_notifications implementation is out of date (though on first glance it seems pretty similar to the implementation in notifications_content.module.)
- The user interface for managing a user's OG subscriptions was removed
However, it's not clear to me whether we want the interface back as it was, or if it's supposed to be changed somehow, and if so, what that change should be.

@Zen, you mentioned that the above referenced issue should be put on hold until this one is fixed. With a bit of clarification I should be able to dive in here with some code.

Thanks!

@ezra: actually, it seems I jumped the gun here. I had a bum DB which exacerbated the issue. I'm going to first merge the UI patch back into 6-2 and we'll take it from there.

Re: UI - I find the present situation rather peculiar. Without notifications_ui installed, the user gets a barebones admin page to manage existing subscriptions, but no option to add a subscription. When the OGN UI is merged, users will be able to administer their group subscriptions without installing notifications_ui. If the add subscriptions form is also merged in, they will be able to add group subscriptions alone etc. etc. This effectively makes the admin UI very inconsistent if other subscription types are also involved.

As above, for the time being, I'm just going to patch the old UI back in and see how we go.

-K

http://drupal.org/cvs?commit=251566

please reopen as needed.

I tried this new approach and code. I didn't see a dev snapshot that included this, so I created a patch.

I tested it and it seems to work in most cases. But when I tried to add a subscription to a content type that already exists (or for "all content types" for a group), then it created a duplicate Group-Type entries below - as you can see in the "new patched version" (notsoliked.png) and "Many duplicates" (duplicatecity.png) attached files. Also, I went over this UI approach with some of our Beta users, and they didn't really like it as much as the older UI.

The older approach for the UI for showing all groups (each as a fieldset) then the content types in each was easier to understand. I have attached a screen shot "Many Duplicates" (duplicatescity.png) of it that I will probably end up using for our production release in a couple of weeks to handle these group subscriptions. It seems to be fairly stable and very easy for the users to understand.

@greg: I'm not able to replicate the duplication issue (with identical parameters for deliver method and frequency). Please test with an up-to-date installation of OG, OGN, notifications and messaging. Notifications usually takes care of duplicates automatically.

The old UI wasn't scaling well for cases where the number of groups were high and did not handle mass updates and pagination very well either.

-K

Ok, I tested this again with the most recent versions.

I am still getting duplicates. When I try different combinations of Group and Type eventually some of the start creating duplicates.

Also, under "Add Subscription" the Groups dropdown is showing all group even if they are unpublished. Probably shouldn't show unpublished groups.

Fixed the unpublished group issue. Re: duplicates - I cannot reproduce. Please detail steps to reproduce in a separate issue.

Marking as fixed.

Subscribing