V4.10.0.00874 Bug + Featurerequest

PHP Newsletter Software/Script und E-Mail-Marketing Software SuperWebMailer

Moderator: mirko

the_scrat
Beiträge: 141
Registriert: 07.09.2010, 16:20

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von the_scrat »

Hallo Mirko,

vielen Dank für die detaillierten Informationen, das hilft mir in jedem Fall schonmal weiter. Einen konflikt mit Mails sich beim Versand überschneiden könnten wird es nicht geben, da dem Kunden nur Mails zum "erneuten" Versand angeboten werden. Daher sollte in diesem Fall nichts passieren. Ich werde den Tipp allerdings berücksichtigen.
Eine API wäre natürlich wirklich toll.

Was den Teil mit der Individualsoftware angeht, verstehe ich dich natürlich vollkommen. Da hast du auch recht. Aber wenn du magst, sende ich unseren Kunden gerne ein freundliches E-Mail mit dem Hinweis, dass der Entwickler ein bestimmtes Kontingent an Anfragen benötigt, damit soetwas eingebaut wird ;-)
Natürlich mach ich das nicht!

Wie du aber einige Beiträge zuvor geschrieben hast, ist diese Funktion ja nur weitere Abfrage. Der Aufwand hält sich also in Grenzen :-) Du könntest ja auch einfach mal Umfragen machen, dann stellt sich ganz schnell raus, was für Wünsche deine Kunden haben. Ich bin mir fast sicher, dass 3/4 aller Kunden lieber ein Problem manuell lösen als sich an den Entwickler zu wenden oder um eine Verbesserung zu bitten.

In diesem Sinne, erstmal danke für die Antwort und Infos...
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

Fällt mir gerade noch ein zu der $statistics_id, wenn in der RStatisticsTableName der Eintrag für den Empfänger mit `Send`='Prepared' enthalten ist, dann darf man den Datensatz nicht löschen, weil er gerade versenden könnte.
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

the_scrat hat geschrieben:
mirko hat geschrieben:
the_scrat hat geschrieben:Hallo Mirko,

ich wollte mich mal erkundigen, ob du schon Zeit hattest, dich mit der Thematik bzgl. der fixen Zeit beim Verschicken eines FollowUps zu beschäftigen.
Ich möchte dir mal einen Auszug einer produktiven History zeigen um damit deutlich zu machen wie gravierend alleine diese 1 Minute pro Tag ist.

Code: Alles auswählen

12/02/11 18:01:02 - Tag 1 für ***********
Bei über 1000 E-Mails für einen Kurs möchte ich nicht wissen zu welcher Zeit eine Mail 500 oder gar die letzte Mail ankommt. Vorallem wenn die Kunden gerne in der früh ihre E-Mail erwarten.
mirko hat geschrieben: Damit beschäftige ich mich nicht, interessiert im Moment niemanden, mal von Dir abgesehen. :)

Weißt du Mirko, mir ist die Funktion generell auch egal, ziemlich egal, nur im Gegensatz zu dir interessiere ich mich dafür, weil unsere Kunden einfach so eine Funktion benötigen! Ich frage so etwas auch nicht an, weil mir langweilig ist oder ich dich ärgern möchte, sondern weil wir konkrete Anfragen dafür haben (und glaub mir, der Wunsch kommt nicht von einer einzelnen Person, sondern von Mehreren). Also was mache ich? Schreibe dem Entwickler, der aber, wie es aussieht, keinen Bock auf Weiterentwicklung und vorallem Kundensupport hat - zumindest für Sachen die "ER" nicht braucht.
Und da du wohl auch noch nichts von Open Source gehört hast oder nichts davon hälst und auch keine Möglichkeit bietest, eigene Funktionen in das Produkt zu bringen, bleibt mir leider nichts anderes übrig als immer wieder solche Wünsche/Anfragen an dich weiterzugeben.

Im Übrigen hat mein Chef deine Antwort ebenfalls gelesen, ein renomierter Trainer für Motivations-/ Persönlichkeitsentwicklung, der nun überlegt ob er dieses Beispiel nicht in seinen Vorträgen/Seminaren hernimmt - im Fall Service und Kundenfreundlichkeit - wie man es nicht machen sollte.
Ich biete Standard-Software an, in Standard-Software kommen nur Funktionen rein, die jeder brauchen könnte. Anhand von Anfragen sehe ich, was so gewünscht wird und dann entscheide ich. Diese Funktion, die du hier willst, hat noch niemand nachgefragt, es interessiert einfach keinen wann die E-Mails ankommen, die müssen nur ankommen. Wünsche gibt es viele aber nicht alle sind umsetzbar, weil diese zu speziell auf den jeweiligen Kunden zugeschnitten sind, also ein Fall für Individual-Software.
Dann noch eine weitere Frage, weil uns in letzter Zeit immer wieder einige Mails erreichen, die sagen, dass die Mails nicht angekommen sein. Hierbei handelt es sich um keinen Fehler im Programm, vielmehr möchte ich nun die Mögilchkeiten von unserer Plattform bieten sich die "nicht erhaltenen Mails" nochmals zuzusenden.

Könntest du mir bitte vielleicht kurz helfen was genau zu tun ist, um eine nochmal an einen Kunden zu schicken. DB technisch. Wie ich selektiere, dass ein Kunde nur die Mails angezeigt bekommt, die er bisher bekommen hat, ist kein Problem, das bekomme ich mit einem Join hin zwischen der Kundentabelle und Referenztabelle.
Reicht es aus, einfach die swm_outqueue zu befüllen? Und welche Daten sind dazu konkret notwendig? Alle Spalten?
Wird beim Befüllen und abarbeiten der Tabelle vom System ein Eintrag des jeweiligen Benutzers in der History gemacht, oder übernimmt das das System in anderern Bereichen bzw. müsste ich mich da selbst drum kümmern und einen Eintrag ergänzen?

Hoffe du verstehst was ich möchte und kannst mir die nötige Auskunft geben, ansonsten verlier ich mich in der Tabellenstruktur ;-)

Danke schonmal
mirko hat geschrieben: Ja ja swm_outqueue befüllen aber lass die Finger davon, das bekommst nicht hin, weil viele IDs notwendig sind.
Die Frage war nicht, "soll ich davon die Finger lassen?", sondern "kannst du mir vielleicht helfen?". Ich habe ein konkretes Problem, welches ich auch ausgibig beschrieben habe. Es hätte ja sein können, dass du mir schreibst, wie ich oder wo ich die nötigen IDs "schneller" finde, denn dass viele IDs notwendig sind, sehe ich ja selbst. Ich erwarte weder, dass du das für mich machst, noch, dass du es einbaust oder sonst etwas.

Aber ich seh schon, ich sollte in Zukunft einfach auf das integrierte Newslettersystem meines CMS setzen und da die nötigen Funktionen einbauen. Da hab ich wenigstens eine Community, die sich über neue Funktionen freut und bin nicht auf engstirnige Entwickler angewiesen.[/quote]

Lass es sein, irgendwann gibt es eine API dann kann man das per API machen. Ansonsten wenn da nur ein Fehler drin ist, kann der ganze Versand schief gehen, das "stürzt komplett" ab, d.h. es geht keine einzige E-Mail mehr raus.

Es ist auch zeitaufwändig und fehleranfällig zu erklären, woher du die IDs bekommst, wenn dann eigenes Risiko.

Die SQL-Anweisung sieht so aus:

INSERT INTO $TableOutqueue SET `CreateDate`=NOW(), `statistics_id`=$statistics_id, `users_id`=$UserId, `Source`='FollowUpResponder', `Source_id`=$arow[FUResponders_id], `Additional_id`=$sendrow[id], `SendId`=$sendrow[id], `maillists_id`=$arow[MailingListId], `recipients_id`=$frow[id], `mtas_id`=$arow[MTA_id], `LastSending`=NOW()

$TableOutqueue => swm_outqueue (Users-Tabelle, beim jeweiligen Admin steht der Tabellenname)

`CreateDate` und `LastSending` => Datum/Uhrzeit jetzt gerade, `LastSending` muss stimmen, weil der sortiert danach

$statistics_id =>
kommt aus der RStatisticsTableName des Follow-Up-Responders, dort muss man zuerst den Eintrag für den Empfänger `recipients_id` und ID der Folge-E-Mail `fumails_id` raussuchen und besten löschen. Wenn er nicht existiert, gibt es nichts zu löschen. Der Datensatz muss dann dort mit gleichem Inhalt wieder rein aber mit `Send`='Prepared'

`users_id` => Ist der jeweilige Admin-Nutzer, die ID muss stimmen sonst stimmt alles andere nicht

`Source`=> immer die Zeichenkette 'FollowUpResponder' das MUSS so sein

`Source_id` => Id des Follow-Up-Responders

`Additional_id` und `SendId` => ID der Follow-Up-E-Mail (aus `FUMailsTableName` des jeweiligen FUResponders)

`maillists_id` => ID der Empfängerliste

`recipients_id` => ID des Empfängers ind er Empfängerliste `maillists_id`

`mtas_id` => ID der Versandvariante, siehe die ID unter Menü Einstellungen - Versandvarianten
the_scrat
Beiträge: 141
Registriert: 07.09.2010, 16:20

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von the_scrat »

mirko hat geschrieben:
the_scrat hat geschrieben:Hallo Mirko,

ich wollte mich mal erkundigen, ob du schon Zeit hattest, dich mit der Thematik bzgl. der fixen Zeit beim Verschicken eines FollowUps zu beschäftigen.
Ich möchte dir mal einen Auszug einer produktiven History zeigen um damit deutlich zu machen wie gravierend alleine diese 1 Minute pro Tag ist.

Code: Alles auswählen

12/02/11 18:01:02 - Tag 1 für ***********
Bei über 1000 E-Mails für einen Kurs möchte ich nicht wissen zu welcher Zeit eine Mail 500 oder gar die letzte Mail ankommt. Vorallem wenn die Kunden gerne in der früh ihre E-Mail erwarten.
mirko hat geschrieben: Damit beschäftige ich mich nicht, interessiert im Moment niemanden, mal von Dir abgesehen. :)

Weißt du Mirko, mir ist die Funktion generell auch egal, ziemlich egal, nur im Gegensatz zu dir interessiere ich mich dafür, weil unsere Kunden einfach so eine Funktion benötigen! Ich frage so etwas auch nicht an, weil mir langweilig ist oder ich dich ärgern möchte, sondern weil wir konkrete Anfragen dafür haben (und glaub mir, der Wunsch kommt nicht von einer einzelnen Person, sondern von Mehreren). Also was mache ich? Schreibe dem Entwickler, der aber, wie es aussieht, keinen Bock auf Weiterentwicklung und vorallem Kundensupport hat - zumindest für Sachen die "ER" nicht braucht.
Und da du wohl auch noch nichts von Open Source gehört hast oder nichts davon hälst und auch keine Möglichkeit bietest, eigene Funktionen in das Produkt zu bringen, bleibt mir leider nichts anderes übrig als immer wieder solche Wünsche/Anfragen an dich weiterzugeben.

Im Übrigen hat mein Chef deine Antwort ebenfalls gelesen, ein renomierter Trainer für Motivations-/ Persönlichkeitsentwicklung, der nun überlegt ob er dieses Beispiel nicht in seinen Vorträgen/Seminaren hernimmt - im Fall Service und Kundenfreundlichkeit - wie man es nicht machen sollte.
Dann noch eine weitere Frage, weil uns in letzter Zeit immer wieder einige Mails erreichen, die sagen, dass die Mails nicht angekommen sein. Hierbei handelt es sich um keinen Fehler im Programm, vielmehr möchte ich nun die Mögilchkeiten von unserer Plattform bieten sich die "nicht erhaltenen Mails" nochmals zuzusenden.

Könntest du mir bitte vielleicht kurz helfen was genau zu tun ist, um eine nochmal an einen Kunden zu schicken. DB technisch. Wie ich selektiere, dass ein Kunde nur die Mails angezeigt bekommt, die er bisher bekommen hat, ist kein Problem, das bekomme ich mit einem Join hin zwischen der Kundentabelle und Referenztabelle.
Reicht es aus, einfach die swm_outqueue zu befüllen? Und welche Daten sind dazu konkret notwendig? Alle Spalten?
Wird beim Befüllen und abarbeiten der Tabelle vom System ein Eintrag des jeweiligen Benutzers in der History gemacht, oder übernimmt das das System in anderern Bereichen bzw. müsste ich mich da selbst drum kümmern und einen Eintrag ergänzen?

Hoffe du verstehst was ich möchte und kannst mir die nötige Auskunft geben, ansonsten verlier ich mich in der Tabellenstruktur ;-)

Danke schonmal
mirko hat geschrieben: Ja ja swm_outqueue befüllen aber lass die Finger davon, das bekommst nicht hin, weil viele IDs notwendig sind.
Die Frage war nicht, "soll ich davon die Finger lassen?", sondern "kannst du mir vielleicht helfen?". Ich habe ein konkretes Problem, welches ich auch ausgibig beschrieben habe. Es hätte ja sein können, dass du mir schreibst, wie ich oder wo ich die nötigen IDs "schneller" finde, denn dass viele IDs notwendig sind, sehe ich ja selbst. Ich erwarte weder, dass du das für mich machst, noch, dass du es einbaust oder sonst etwas.

Aber ich seh schon, ich sollte in Zukunft einfach auf das integrierte Newslettersystem meines CMS setzen und da die nötigen Funktionen einbauen. Da hab ich wenigstens eine Community, die sich über neue Funktionen freut und bin nicht auf engstirnige Entwickler angewiesen.
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

the_scrat hat geschrieben:Hallo Mirko,

ich wollte mich mal erkundigen, ob du schon Zeit hattest, dich mit der Thematik bzgl. der fixen Zeit beim Verschicken eines FollowUps zu beschäftigen.
Ich möchte dir mal einen Auszug einer produktiven History zeigen um damit deutlich zu machen wie gravierend alleine diese 1 Minute pro Tag ist.

Code: Alles auswählen

12/02/11 18:01:02 - Tag 1 für ***********
Bei über 1000 E-Mails für einen Kurs möchte ich nicht wissen zu welcher Zeit eine Mail 500 oder gar die letzte Mail ankommt. Vorallem wenn die Kunden gerne in der früh ihre E-Mail erwarten.
Damit beschäftige ich mich nicht, interessiert im Moment niemanden, mal von Dir abgesehen. :)
Dann noch eine weitere Frage, weil uns in letzter Zeit immer wieder einige Mails erreichen, die sagen, dass die Mails nicht angekommen sein. Hierbei handelt es sich um keinen Fehler im Programm, vielmehr möchte ich nun die Mögilchkeiten von unserer Plattform bieten sich die "nicht erhaltenen Mails" nochmals zuzusenden.

Könntest du mir bitte vielleicht kurz helfen was genau zu tun ist, um eine nochmal an einen Kunden zu schicken. DB technisch. Wie ich selektiere, dass ein Kunde nur die Mails angezeigt bekommt, die er bisher bekommen hat, ist kein Problem, das bekomme ich mit einem Join hin zwischen der Kundentabelle und Referenztabelle.
Reicht es aus, einfach die swm_outqueue zu befüllen? Und welche Daten sind dazu konkret notwendig? Alle Spalten?
Wird beim Befüllen und abarbeiten der Tabelle vom System ein Eintrag des jeweiligen Benutzers in der History gemacht, oder übernimmt das das System in anderern Bereichen bzw. müsste ich mich da selbst drum kümmern und einen Eintrag ergänzen?

Hoffe du verstehst was ich möchte und kannst mir die nötige Auskunft geben, ansonsten verlier ich mich in der Tabellenstruktur ;-)

Danke schonmal
Ja ja swm_outqueue befüllen aber lass die Finger davon, das bekommst nicht hin, weil viele IDs notwendig sind.
the_scrat
Beiträge: 141
Registriert: 07.09.2010, 16:20

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von the_scrat »

Hallo Mirko,

ich wollte mich mal erkundigen, ob du schon Zeit hattest, dich mit der Thematik bzgl. der fixen Zeit beim Verschicken eines FollowUps zu beschäftigen.
Ich möchte dir mal einen Auszug einer produktiven History zeigen um damit deutlich zu machen wie gravierend alleine diese 1 Minute pro Tag ist.

Code: Alles auswählen

12/02/11 18:01:02 - Tag 1 für ***********
12/03/11 18:01:02 - Tag 2 für ***********
12/04/11 18:02:02 - Tag 3 für ***********
12/05/11 18:02:01 - Tag 4 für ***********
12/06/11 18:02:02 - Tag 5 für ***********
12/07/11 18:02:02 - Tag 6 für ***********
12/08/11 18:04:02 - Tag 7 für ***********
12/09/11 18:04:01 - Tag 8 für ***********
12/10/11 18:03:02 - Tag 9 für ***********
12/11/11 18:03:02 - Tag 10 für ***********
12/12/11 18:04:02 - Tag 11 für ***********
12/13/11 18:04:02 - Tag 12 für ***********
12/14/11 18:04:02 - Tag 13 für ***********
12/15/11 18:05:02 - Tag 14 für ***********
--- MANUELL ZEIT ZURÜCKGESETZT auf 6:00 Uhr ---
12/16/11 06:01:02 - Tag 15 für ***********
12/17/11 06:01:02 - Tag 16 für ***********
12/18/11 06:02:02 - Tag 17 für ***********
12/19/11 06:03:02 - Tag 18 für ***********
12/20/11 06:04:01 - Tag 19 für ***********
12/21/11 06:04:02 - Tag 20 für ***********
12/22/11 06:04:01 - Tag 21 für ***********
12/23/11 06:04:02 - Tag 22 für ***********
12/24/11 06:05:02 - Tag 23 für ***********
12/25/11 06:05:02 - Tag 24 für ***********
12/26/11 06:05:05 - Tag 25 für ***********
12/27/11 06:06:05 - Tag 26 für ***********
12/28/11 06:06:05 - Tag 27 für ***********
12/29/11 06:07:05 - Tag 28 für ***********
12/30/11 06:07:04 - Tag 29 für ***********
12/31/11 06:07:04 - Tag 30 für ***********
01/01/12 06:08:05 - Tag 31 für ***********
01/02/12 06:08:03 - Tag 32 für ***********
01/03/12 06:08:04 - Tag 33 für ***********
01/04/12 06:10:03 - Tag 34 für ***********
01/05/12 06:10:04 - Tag 35 für ***********
01/06/12 06:11:04 - Tag 36 für ***********
01/07/12 06:12:04 - Tag 37 für ***********
01/08/12 06:13:03 - Tag 38 für ***********
01/09/12 06:13:02 - Tag 39 für ***********
01/10/12 06:13:04 - Tag 40 für ***********
01/11/12 06:13:04 - Tag 41 für ***********
01/12/12 06:14:04 - Tag 42 für ***********
01/13/12 06:14:04 - Tag 43 für ***********
01/14/12 06:15:04 - Tag 44 für ***********
01/15/12 06:15:04 - Tag 45 für ***********
01/16/12 06:15:04 - Tag 46 für ***********
01/17/12 06:15:04 - Tag 47 für ***********
01/18/12 06:16:04 - Tag 48 für ***********
01/19/12 06:17:05 - Tag 49 für ***********
01/20/12 06:18:05 - Tag 50 für ***********
01/21/12 06:19:04 - Tag 51 für ***********
01/22/12 06:19:05 - Tag 52 für ***********
01/23/12 06:20:05 - Tag 53 für ***********
01/24/12 06:21:04 - Tag 54 für ***********
01/25/12 06:22:05 - Tag 55 für ***********
01/26/12 06:22:05 - Tag 56 für ***********
01/27/12 06:23:04 - Tag 57 für ***********
01/28/12 06:24:04 - Tag 58 für ***********
01/29/12 06:24:04 - Tag 59 für ***********
01/30/12 06:24:04 - Tag 60 für ***********
01/31/12 06:24:05 - Tag 61 für ***********
02/01/12 06:24:05 - Tag 62 für ***********
02/02/12 06:25:05 - Tag 63 für ***********
02/03/12 06:25:03 - Tag 64 für ***********
02/04/12 06:25:03 - Tag 65 für ***********
02/05/12 06:25:03 - Tag 66 für ***********
02/06/12 06:25:03 - Tag 67 für ***********
02/07/12 06:26:03 - Tag 68 für ***********
02/08/12 06:27:03 - Tag 69 für ***********
02/09/12 06:28:05 - Tag 70 für ***********
02/10/12 06:29:05 - Tag 71 für ***********
02/11/12 06:29:05 - Tag 72 für ***********
02/12/12 06:29:04 - Tag 73 für ***********
02/13/12 06:30:04 - Tag 74 für ***********
02/14/12 06:30:04 - Tag 75 für ***********
02/15/12 06:30:06 - Tag 76 für ***********
02/16/12 06:31:05 - Tag 77 für ***********
02/17/12 06:32:04 - Tag 78 für ***********
02/18/12 06:33:02 - Tag 79 für ***********
02/19/12 06:33:03 - Tag 80 für ***********
02/20/12 06:33:03 - Tag 81 für ***********
02/21/12 06:33:07 - Tag 82 für ***********
02/22/12 06:34:02 - Tag 83 für ***********
02/23/12 06:35:02 - Tag 84 für ***********
02/24/12 06:35:03 - Tag 85 für ***********
02/25/12 06:36:03 - Tag 86 für ***********
02/26/12 06:37:02 - Tag 87 für ***********
02/27/12 06:38:02 - Tag 88 für ***********
02/28/12 06:38:02 - Tag 89 für ***********
02/29/12 06:38:02 - Tag 90 für ***********
03/01/12 06:39:02 - Tag 91 für ***********
03/02/12 06:39:02 - Tag 92 für ***********
03/03/12 06:40:02 - Tag 93 für ***********
03/04/12 06:40:03 - Tag 94 für ***********
03/05/12 06:40:03 - Tag 95 für ***********
03/06/12 06:41:02 - Tag 96 für ***********
03/07/12 06:41:02 - Tag 97 für ***********
03/08/12 06:41:02 - Tag 98 für ***********
03/09/12 06:41:03 - Tag 99 für ***********
03/10/12 06:42:02 - Tag 100 für ***********
03/11/12 06:43:02 - Tag 101 für ***********
03/12/12 06:43:02 - Tag 102 für ***********
03/13/12 06:44:01 - Tag 103 für ***********
03/14/12 06:44:02 - Tag 104 für ***********
03/15/12 06:46:02 - Tag 105 für ***********
03/16/12 06:46:02 - Tag 106 für ***********
03/17/12 06:46:01 - Tag 107 für ***********
03/18/12 06:46:01 - Tag 108 für ***********
03/19/12 06:46:02 - Tag 109 für ***********
03/20/12 06:46:02 - Tag 110 für ***********
03/21/12 06:48:02 - Tag 111 für ***********
03/22/12 06:48:03 - Tag 112 für ***********
03/23/12 06:49:03 - Tag 113 für ***********
03/24/12 06:50:02 - Tag 114 für ***********
03/25/12 06:50:03 - Tag 115 für ***********
03/26/12 06:51:02 - Tag 116 für ***********
03/27/12 06:51:02 - Tag 117 für ***********
03/28/12 06:52:02 - Tag 118 für ***********
03/29/12 06:52:02 - Tag 119 für ***********
03/30/12 06:52:02 - Tag 120 für ***********
03/31/12 06:52:02 - Tag 121 für ***********
04/01/12 06:52:03 - Tag 122 für ***********
04/02/12 06:53:02 - Tag 123 für ***********
04/03/12 06:53:02 - Tag 124 für ***********
04/04/12 06:54:03 - Tag 125 für ***********
04/05/12 06:54:03 - Tag 126 für ***********
04/06/12 06:54:03 - Tag 127 für ***********
04/07/12 06:54:03 - Tag 128 für ***********
04/08/12 06:55:02 - Tag 129 für ***********
04/09/12 06:55:02 - Tag 130 für ***********
04/10/12 06:56:06 - Tag 131 für ***********
04/11/12 06:57:06 - Tag 132 für ***********
Bei über 1000 E-Mails für einen Kurs möchte ich nicht wissen zu welcher Zeit eine Mail 500 oder gar die letzte Mail ankommt. Vorallem wenn die Kunden gerne in der früh ihre E-Mail erwarten.

Dann noch eine weitere Frage, weil uns in letzter Zeit immer wieder einige Mails erreichen, die sagen, dass die Mails nicht angekommen sein. Hierbei handelt es sich um keinen Fehler im Programm, vielmehr möchte ich nun die Mögilchkeiten von unserer Plattform bieten sich die "nicht erhaltenen Mails" nochmals zuzusenden.

Könntest du mir bitte vielleicht kurz helfen was genau zu tun ist, um eine nochmal an einen Kunden zu schicken. DB technisch. Wie ich selektiere, dass ein Kunde nur die Mails angezeigt bekommt, die er bisher bekommen hat, ist kein Problem, das bekomme ich mit einem Join hin zwischen der Kundentabelle und Referenztabelle.
Reicht es aus, einfach die swm_outqueue zu befüllen? Und welche Daten sind dazu konkret notwendig? Alle Spalten?
Wird beim Befüllen und abarbeiten der Tabelle vom System ein Eintrag des jeweiligen Benutzers in der History gemacht, oder übernimmt das das System in anderern Bereichen bzw. müsste ich mich da selbst drum kümmern und einen Eintrag ergänzen?

Hoffe du verstehst was ich möchte und kannst mir die nötige Auskunft geben, ansonsten verlier ich mich in der Tabellenstruktur ;-)

Danke schonmal
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

Es wird in der Referenztabelle nachgeschaut, wer fällig ist bzw. ist derjenige nicht drin, derjenige hinzugefügt. Ist er fällig, dann kommt er in die Ausgangstabelle und dann wird die E-Mail versendet.
the_scrat
Beiträge: 141
Registriert: 07.09.2010, 16:20

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von the_scrat »

ok, verstehe. Die Warscheinlichkeit, dass das passiert ist zwar recht gering, aber passieren könnte es. Rein theoretisch sollte es ja dann genügen, fall es den Empfänger tatsächlich schon gibt, ein Update der ID zu machen. Dies findet ja sowieso nur einmalig statt. Rein theoretisch könnte im schlimmsten Fall jemand die erste und dann x-te Mail erhalten. Glaub ich zwar jetzt nicht. Wichtig war mir nur, dass diese Tabelle die einzige ist in der ich etwas eintragen soll. Oder wird beim Cronjob zwar in der Referenztabelle nachgesehen wer "fällig" ist und dann wo anders in die Warteschlange gepackt?
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

Ja genau du setzt nur den Eintrag in die ml_fu_ref mit der entsprechenden ID. Wenn die ID und sort_order identisch sind, dann spielt es keine Rolle, welche du nimmst. Du musst beim Schreiben in die ml_fu_ref aber abprüfen ob es für den Empfänger bereits einen Eintrag gibt, nicht das nach dem Anlegen des Empfängers sofort das CronJob-Script zuschlägt und die erste E-Mail versendet wird.
the_scrat
Beiträge: 141
Registriert: 07.09.2010, 16:20

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von the_scrat »

Das ist wirklich schade, aber verständlich, dass du natürlich noch andere Probleme hast.

Jetzt hab ich aber trotzdem nochmal kurz eine Frage, weil ich grad die DB durchgeforstet habe. Denn ich möchte wirklich auf die Mehrfachlisten verzichten. Für den Teil, dass ein Empfänger nur einen Teil des Kurses (von Beginn) macht, sollte kein Problem sein. Den lass ich regulär in die große Liste laufen und sende nach x-Tagen einfach den deaktivierungs"befehl". Entscheidet er sich den Kurs fortzusetzen, aktiviere ich ihn und weiter gehts.

Aber die andere Aktion, dass ein Benutzer an einer bestimmten Position starten soll müsste ja lösbar sein (im Notfall indem ich selbst eine DB Verbindung aufbau und einen Datensatz hinzufüge).

Gerade habe ich geprüft was du in einem der letzten Postings angesprochen hast mit ID und sort_order. Diese ids sind exakt gleich. Es wurde also nichts sortiert. Reicht es also aus, wenn (automatisiert) nach der regulären Erstellung über die API direkt in der *_ml_fu_ref einen Eintrag erzeugen lasse mit der ID, einem vergangenen Versanddatum und der ID des zu versendenden Mailings? Richtig? Muss ich sonst noch einen Eintrag beachten in einer Tabelle beachten? Als ID wird dann somit die sort_order ID angegeben (welche bei mir ja sowieso exakt die ID der Tabelle ist).

Denn wenn das der ganze Hexen"spuk" ist, bekomm ich es auch erstmal so hin und verbringe die Zeit lieber damit in meinem CMS einen Counter einzubauen, der die Leute nach einer gewissen Zeit per API deaktviert bzw. beim Kauf der Fortsetzungskurse direkt an die korrekte Position setzt (anhand eines zusätzlichen Eintrages in *_ml_fu_ref).
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

Im Moment gibt es das nicht, an SuperWebMailer mache ich jetzt erstmal gar nichts. SuperMailer ist jetzt dran, der muss 64bit werden und das macht schon genug Probleme, die irgendwie eine Lösung brauchen.
the_scrat
Beiträge: 141
Registriert: 07.09.2010, 16:20

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von the_scrat »

Naja, ich wollte eigentlich darauf hinaus, ob Du (der das System ja wesentlich besser kennt) das nicht machen könntest oder einbauen könntest. Ich persönlich würde gerne per API einfach nur die Daten übergeben Userdaten, ListenID und MailingID und das System soll den Empfänger in die entsprechende Liste aufnehmen und direkt im Anschluss an die entsprechende Position setzen. Manuell kann ich das ja "rein theoretisch" auch machen. Empfänger wird in der Liste hinzugefügt. Ich gehe in die Optionen des Empfängers und wähle als Folge E-Mail die gewünschte. Dazu muss ja noch nichtmal ein Versand erfolgt sein, richtig?

Zumindest sehe ich diese Funktion für nützlich, da ich mir wirklich spare nochmal über 1000 E-Mails anzulegen mit exakt dem selben Inhalt.

Die API ist ja eh so ein mächtiges Werkzeug und du bräuchtest es nur in die schon bestehende Funktion integrieren.... wenn möglich. Geht das? Weil selbst an der DB rumarbeiten ist mir zu riskant, weil ich eben nicht die ganzen Hintergründe kenne, welcher Wert muss wohin und welche Statistik muss wann wo angepasst werden. Und das könnte man eben durch einen automatismus umgehen.
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

Ja aber dazu müsstest du aber in die Datenbank greifen und den Eintrag umsetzen. Wichtig dabei, setzt man die ID der E-Mail auf einen kleineren Wert und die E-Mail wurde bereits versendet, dann muss man zusätzlich noch den Versandeintrag in der Statistik-Tabelle löschen, sonst wird die E-Mail nicht nochmals versendet.
the_scrat
Beiträge: 141
Registriert: 07.09.2010, 16:20

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von the_scrat »

Ja von der Struktur her ist das klar, dass ich nur die benötigten Mails in den FollowUp packen muss. Aber was macht denn die Funktion "Folge E-Mail setzen"? Die setzt doch den Empfänger an eine andere Position innerhalb einer existierenden Liste, oder nicht?
Benutzeravatar
mirko
Beiträge: 22869
Registriert: 25.11.2001, 15:14
Wohnort: Leipzig
Kontaktdaten:

Re: V4.10.0.00874 Bug + Featurerequest

Beitrag von mirko »

Du musst den gleichen Responder nochmals anlegen aber nur mit den E-Mails, die gebraucht werden. Alles andere kannst du nicht "faken", denn der Responder fängt immer mit der ersten E-Mail in der Liste an, nicht mit irgendeiner in der Liste.
Antworten