Don't send blog announcement, when `draft` is specified in categories

[Ryan J Ollos]

The FullBlogPlugin has a plugin that implements draft functionality. A draft is specified by entering draft in Categories. It would be a nice feature for the FullBlogNotificationPlugin if emails were not sent when draft was specified in Categories.

[Ryan J Ollos]

See also #5556.

[Ryan J Ollos]

I'm starting to work on implementing this feature. Initially, I'll aim to have the email sent only to the blog author if draft is specified in the list of tags.

Once that is working, I'll consider adding the following additional logic:

• Only implement the aforementioned functionality if ​BlogDraftPlugin is installed.
• Add the following trac.ini options:
  • notify_if_draft
  • notify_author_if_draft, which can over-ride the always_notify_author option.

If anyone else is interested in this feature, please let me know if you have any comments.

[osimons]

The draft plugin is really just an example, and other variations may appear in other plugins. It would seem to me that the general solution would be to have notification plugin check permission to recipients, and only send to recipients that have permission to read the blog post.

Disclaimer: I don't know any FullBlogNotificationPlugin details - only the FullBlogPlugin with sample plugins.

[Ryan J Ollos]

Reassigning ticket since I am now maintainer of the plugin.

[Ryan J Ollos]

Moving this over to the FullBlogAnnouncementsPlugin to work on it there.

[Robert Corsaro]

I have a trunk version of FullBlogAnnouncements in AnnouncerPlugin trunk. Please use that as the base for any >0.11 work that you do.

[Ryan J Ollos]

Replying to doki_pen: In regard to owner changed from doki_pen to ixokai. in comment:7, did you intend to do that? It might be that the component has not been transferred to you from the previous owner (I saw this behavior with some plugins I adopted), and to fix it you just need to send an email to the tho admin otaku42.

[Ryan J Ollos]

Replying to doki_pen:

I have a trunk version of FullBlogAnnouncements in AnnouncerPlugin trunk. Please use that as the base for any >0.11 work that you do.

Sorry that I haven't had any time to follow-up on things lately, but I intend to continue with testing and development soon.

Do you intend to keep all of the plugins with the AnnouncerPlugin? I think that is a good idea, and if you do intend to do that I think it would also be good to remove the existing pages for FullBlogAnnouncementsPlugin and the other AnnouncerPlugin plugins, and make them sub-wiki-pages of the AnnouncerPlugin.

I'd be happy to help with this, I just don't want to do anything with the documentation that is outside of whatever you have in mind.

[anonymous]

Sounds good. Don't worry about me, I'm pretty easy going. I'm just happy to have any help that I can get!

[Ryan J Ollos]

• FullBlogAnnouncementsPlugin has been marked as obsolete.
• Relevant parts of wiki page have been moved to AnnouncerPlugin/PluginSupport/FullBlogPlugin.
• A TitleIndex has been added to the main page of the AnnouncerPlugin to list plugins: AnnouncerPlugin#Plugins

I'll do the same for the other two AnnouncerPlugin plugins if it looks okay with you.

[Steffen Hoffmann]

This is just a friendly reminder, that things seem to got stuck by not having the right persons filled into the right fields of this ticket.

Ryan shouldn't wait forever, if he's still up for the task of reorganizing wiki pages for AnnouncerPlugin plugins, right? Let him go on, please.

[Ryan J Ollos]

Ticket for this same feature in the FullBlogNotificationPlugin is #7604.

[Robert Corsaro]

Proceed! Proceed!

[Robert Corsaro]

So I've resumed work and I'm wondering were we are with this? I like the idea of using permissions to stop drafts from being sent. This is something I will implement globally in announcer via the filter interface (which I was going to drop, but I'm not going to now). On concern I have, although not a big concern, is that the announcement will show the post as modified instead of new when it changes from draft to live. I guess this should really be handled by the event publisher and not announcer. But think about it. When going from draft to live, issue a created event, instead of a modified event. Or even a new type of event called 'published' or something. For now, I'll leave things as is and you'll have to wait for the permissions to be put in place to get this functionality.

[Steffen Hoffmann]

Replying to rjollos:

Obviously not true, sorry. I'm just going through ticket to set the stage for squeezing more Announcer issues as time permits.

[Ryan J Ollos]

Replying to hasienda:

Obviously not true, sorry.

I've used the Priority = high on my projects to generate a list what I will work on next. I understand that this will cause problems when collaborating on project, so I will find some other way to track tickets that need attention.