I would like to be able to arrange newsletters into groups. Since newsletters are already defined as taxonomy terms, I figured that the most logical option would be to use the vocabulary's hierarchy. It's not hard to change the vocab's hierarchy setting from 'disabled' to 'single'. This did not cause errors or unexpected behaviour on my Drupal 5 testsite. (If I can get this to work, I want to use it on a D5 site.)

The next step involves more work. I don't want the parent terms to be selectable as newsletters, because they're only meant for grouping. This means that in a select box, the parent must become an <optgroup> instead of an <option>. There are a lot of screens where the list of newsletters is presented to the user: node/add/simplenews, admin/content/newsletters/types, admin/content/newsletters/users/import, to name a few.

I made a start with patching simplenews.module, but I found that I had to build the list of available newsletters over and over again. (The patch against 5.x-1.5 is attached to this issue - pages changed so far are node/add/simplenews, admin/content/newsletters/types and admin/content/newsletters/users.) If we really want to implement this, I think it might be good to create a single function which generates the option list for all different pages, but I'm not planning to do so much work on the Drupal 5 version of simplenews, now that 6.x-1.0 is in beta.

I'd like to know if there are more people interested in this kind of functionality and what your thoughts are about this approach in general.

CommentFileSizeAuthor
simplenews_grouped.module.patch4.01 KBmarcvangend
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sutharsan’s picture

I have no objections against the single/multi selection. But changing the select list is a taxonomy selection thing and is applicable to more situations than just simplenews. I like to keep simplenews simple (as far as possible) and this does not fit in.

marcvangend’s picture

Status: Active » Closed (won't fix)

The taxonomy select list is indeed applicable to more situations, but I'm changing only one of those situations - the others are untouched. That's the great thing about hook_form_alter, isn't it?

For the rest, think I have to agree with you. The more I look into it, the more I see how much code would have to be changed to make this not only work, especially if we want clean code and an intuitive admin interface. Speaking for myself, grouping isn't worth that much work.

I will just think of this as an interesting theory and I'm changing the issue status to won't fix.