Bug #34432
Recipientlist not updated on draft newsletter creation / re-creation
100%
Description
Hey there....
i've been using the draft templates für newsletters for a while now and even though it works very well i noticed a bug:
when the sheduler-task creates the newsletter it fetches the new content but sticks to the recipient list from the time the draft was created the very first time. so all recipients that are inserted to the recipient list after the first creation don't get the newsletter.
it's probably just a small change that's neccessary here, but i'm just not familiar enough with the code...
i hope someone has the time to find a fix for this as this bug reduces the sense of an auto-created newsletter quite a bit since new people won't get it unless you re-create the template (but then there's no difference to a non-draft version)
thanks for all the good work!
cheers,
Markus
p.s.:
i'm using release-version 2.7.0 of directmail
please let me know if this issue might be solved in the svn version ...
Related issues
History
#1
Updated by Daniel Gäumann about 7 years ago
- File batch_bug_34432_v2.7.0 added
- % Done changed from 0 to 40
Markus Greulich wrote:
Hey there....
i've been using the draft templates für newsletters for a while now and even though it works very well i noticed a bug:when the sheduler-task creates the newsletter it fetches the new content but sticks to the recipient list from the time the draft was created the very first time. so all recipients that are inserted to the recipient list after the first creation don't get the newsletter.
it's probably just a small change that's neccessary here, but i'm just not familiar enough with the code...
i hope someone has the time to find a fix for this as this bug reduces the sense of an auto-created newsletter quite a bit since new people won't get it unless you re-create the template (but then there's no difference to a non-draft version)
thanks for all the good work!
cheers,
Markusp.s.:
i'm using release-version 2.7.0 of directmail
please let me know if this issue might be solved in the svn version ...
I made a patch, solving this Bug real quick. Maybe someone can use it. It's based on v 2.7.0.
Dont forget to add the right be_groups to de _cli_scheduler user, which can select tt_address and fe_users records.
#2
Updated by Stefano Cecere about 7 years ago
- Target version set to 3.0.3
- % Done changed from 40 to 100
i found the same problem today (using 3.0.2)
applied the patch and now it works perfecly
so, +1 by reading and testing , for this patch!
#3
Updated by Stefano Cecere about 7 years ago
it seems it works well with static recipeints list, but not with "from pages" ones
i'm digging into it
#4
Updated by Markus Greulich about 7 years ago
- % Done changed from 100 to 90
i just noticed that too, it seems the recipients can't be read when invoked by the scheduler...
at least for me it didn't send any mails then...
if you can solve this, please post here, i would need this quite urgent...
Stefano Cecere wrote:
it seems it works well with static recipeints list, but not with "from pages" ones
i'm digging into it
#5
Updated by Stefano Cecere about 7 years ago
i solved: you have to assign a DB mount to the _cli_scheduler user!
(it is the first time i have to add access permission to this bot :)
#6
Updated by Stefano Cecere about 7 years ago
- % Done changed from 90 to 100
#7
Updated by Stefano Cecere about 7 years ago
note: Daniel wrote about it, in his patch message! how blind we were!!!
#8
Updated by Markus Greulich about 7 years ago
I just figured that as well... and wanted to inform you here...
changed the permissions and now it works well...
tricky part was, when i tried it first i manually startet the task in scheduler, so it used my userrights not the _cli_scheduler rights...
thanks to both of you!
Stefano Cecere wrote:
i solved: you have to assign a DB mount to the _cli_scheduler user!
(it is the first time i have to add access permission to this bot :)
#9
Updated by Ivan Dharma Kartolo about 7 years ago
- Status changed from New to Under Review
- Assignee set to Ivan Dharma Kartolo
#10
Updated by Ivan Dharma Kartolo about 7 years ago
hmmm.. this one will break old draft task... user has to be warned to recreate their draft jobs...
#11
Updated by Ivan Dharma Kartolo about 7 years ago
- Target version changed from 3.0.3 to 3.1.0
#12
Updated by Enrique Moreno almost 7 years ago
Could someone please make a patch for v3.0.3? I've tried adapting it myself, but it didnt work.
#13
Updated by Stefano Cecere almost 7 years ago
- File patch_34432_3.0.4.diff View added
here is the patch for direct_mail 3.0.4
#14
Updated by Stefano Cecere about 6 years ago
Hi couldn't you review this patch?
i'm using it since a lot and it works perfectly..
now i'm updating to 3.1.2 because of the security patch so i checked if you had put this feature in...
#15
Updated by Bernhard Kraft about 6 years ago
- TYPO3 Version set to 4.5
Stefano Cecere wrote:
Hi couldn't you review this patch?
Hi Stefano,
We are using the draft feature for a newsletter which gets sent on a weekly basis. I will try to have a look at this problem. Until now I didn't really recognize it as we re-saved the draft record quite some time for debugging purposes.
One question: How are you testing draft records? I always re-edit the draft record and set the recipient to the test-groups I created. If I finished testing I set it back to the real recipients. Maybe this usage is responsible for not letting me notice the bug.
#16
Updated by Markus Knarz about 6 years ago
Hi,
When I start the task to create a mail from draft manually, works perfect with the patch.
But when these task starts with a server cronjob then create a mail with an empty recipient list.
#17
Updated by Bernhard Kraft about 6 years ago
The supplied patch of course solves the problem. But if you take a look at the methods:
- mod3/class.tx_directmail_recipient_list.php: function cmd_compileMailGroup($group_uid)
- mod2/class.tx_directmail_dmail.php: protected function getSingleMailGroup($group_uid)
you will notice that both are almost identical (duplicate code!). The later one is used from within:
- mod2/class.tx_directmail_dmail.php: protected function cmd_compileMailGroup(array $groups)
I guess instead of making an instance of the SOBE class those methods which are library methods anyways should get moved to somewhere else (tx_directmail_static ?) and used accordingly. Then this new method could get called directly from within the scheduler task to update the recipient list when creating a new sys_dmail record from a draft template.
This would be the cleanest solution. I also opt for NOT putting this methods into tx_directmail_static but rather into a class file on it's own which has to get instanciated. This solves the problem of passing many member variables ($this->perms_clause, $this->userTable, $this->id, $this->fieldList) to every method and additional eliminates the complete duplication of "function update_specialQuery()" !
#18
Updated by Bernhard Kraft about 6 years ago
Markus Knarz wrote:
When I start the task to create a mail from draft manually, works perfect with the patch.
But when these task starts with a server cronjob then create a mail with an empty recipient list.
You have to assign appropriate user rights to the _cli_scheduler user:
- Give correct access rights to the page
- Add a DB mount to the user
I don't know if it is required to assign the _cli_scheduler user to a group having read access to the pages/tt_address table.
#19
Updated by Stefano Cecere about 6 years ago
- File patch_34432_3.1.2.diff View added
here's the patch updated for direct_mail 3.1.2
@ bernhard: i think you are right on your optimizations.. but now i have no power to code them...
meanwhile let's use the pragmatical working patch! :)
#20
Updated by Bjoern Jacob over 5 years ago
Beside from merging the patch to the code the note of Bernhad Kraft should be added to the manual.
#21
Updated by Jens Schmietendorf about 5 years ago
The patch works fine for 4.0.0
with a small modification
$SOBE = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance( 'tx_directmail_dmail' );
instead of
$SOBE = t3lib_div::makeInstance( 'tx_directmail_dmail' );
Do we always have to patch future versions of direct mail,
or is it possible to integrate the working patch? ;-)
#22
Updated by Gerrit Code Review about 5 years ago
Patch set 1 for branch master of project TYPO3CMS/Extensions/direct_mail has been pushed to the review server.
It is available at http://review.typo3.org/34490
#23
Updated by Kaan Sanli over 3 years ago
- File patch_34432_4.1.0.diff View added
I had the same problem with direct_mail 4.1.0
Here is my modification of the patch, working for 4.1.0.
@Ivan: Is this problem still occuring in 5.x ?
#24
Updated by Patrick no-lastname-given almost 3 years ago
- Target version changed from 3.1.0 to 5.1
- TYPO3 Version changed from 4.5 to 7
The issue still exist with direct_mail 5.1.1 under TYPO3 7.6.16