partner management extension

[Ronald Steiner]

Hi List,

I'm setting up a larger web project and am looking for an extension to
fulfill this tasks:

1) Storing and checking information of people
- e-mail, address, name, photo, notes, attended workshop A / B / C / D /
....

2) Sending personalized newsletters to people who:
- live in a certain country,
- attended workshop A and D but not E
- ...

3) Checking information:
- who attended Workshop A and C?
- what information is there for "name x"
- ...

What extensions could you recommend for this tasks?

#### tt_address #####
The "old" address database. The big advantage seams to me that there are
a lot of extensions who base on it. So I could possibly realize a
newsletter as required with direct_mail_subscription and direct_mail
In addition there are lots of interesting extensions which could come in
handy later like: rggooglemap, addressgroups, ...

#### tx_party / wec_people / partner ####
I am still confused which of this extensions is the most current. David
Brühlmeier seems to started with tx_party. Then the "web empowered
chruch" carried the concept on in wec_people. partner is now is newly
updated by David Brühlmeier again. In general the concept of this
extensions looks brilliant. I'm just wondering is one of this extensions
a good alternative to tt_address? Which one would you recommend? How is
your experience with this extensions? Is there an extension for sending
personalized newsletters with data from one of this extensions? Is there
a way to use other tt_address extensions with this extensions? Is it
worth trying the "new" concept, or is it just a lot of hassle? The data
structure of tt_address might be a bit old fashioned, but there are a
lot of extensions for tt_address, which might overcome this problem.

What do you think? What are your experiences?

greetings

Ron
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Ron,

> I am still confused which of this extensions is the most current. David
> Brühlmeier seems to started with tx_party. Then the "web empowered
> chruch" carried the concept on in wec_people. partner is now is newly
> updated by David Brühlmeier again. In general the concept of this
> extensions looks brilliant. I'm just wondering is one of this extensions
> a good alternative to tt_address? Which one would you recommend?

Yes of course tx_party (= wec_people) is the better choice. However the
tx_party has not been published yet, because it is not finished and the
other extensions still need modifications to use it in the future.

You may choose now only among tt_address and fe_users or write your own
modifications.

- Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi Franz,

fe_users does store mail and address as well? I thought it's only for
users to login the Front-End.
Did you already set up a personalized newsletter with wec_people? What
further extensions are necessary? How does it work?

greetings

Ron

Franz Holzinger schrieb:

> Hello Ron,
>
>> I am still confused which of this extensions is the most current.
>> David Brühlmeier seems to started with tx_party. Then the "web
>> empowered chruch" carried the concept on in wec_people. partner is now
>> is newly updated by David Brühlmeier again. In general the concept of
>> this extensions looks brilliant. I'm just wondering is one of this
>> extensions a good alternative to tt_address? Which one would you
>> recommend?
>
> Yes of course tx_party (= wec_people) is the better choice. However the
> tx_party has not been published yet, because it is not finished and the
> other extensions still need modifications to use it in the future.
>
> You may choose now only among tt_address and fe_users or write your own
> modifications.
>
> - Franz

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Ron,

> fe_users does store mail and address as well? I thought it's only for
> users to login the Front-End.

Yes, the address and email is also stored in fe_users. This is supported
by sr_feuser_register.

> Did you already set up a personalized newsletter with wec_people? What
> further extensions are necessary? How does it work?

No, I could not use wec_people yet, because some things are missing. And
IMHO it is not yet supported by newsletter extensions.

Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi,

so best extension to use in my situation is fe_users and sr_feuser_register?
Or do you recommend tt_address for my situation?

When wec_people is released I can again think about switching.

greetings

Ron


Franz Holzinger schrieb:

> Hello Ron,
>
>> fe_users does store mail and address as well? I thought it's only for
>> users to login the Front-End.
>
> Yes, the address and email is also stored in fe_users. This is supported
> by sr_feuser_register.
>
>> Did you already set up a personalized newsletter with wec_people? What
>> further extensions are necessary? How does it work?
>
> No, I could not use wec_people yet, because some things are missing. And
> IMHO it is not yet supported by newsletter extensions.
>
> Franz

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Ron,

> so best extension to use in my situation is fe_users and
> sr_feuser_register?
> Or do you recommend tt_address for my situation?

You can choose among both tables. However if you want to use logged in
FE users or a shop with tt_products then you should stick to fe_users.

Franz

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Andreas Burg]

Hello Franz,

can't find fe_users in the repository. Where is it?

Andreas
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi Franz,

which Newsletter-Extension would you recommend to use with fe_users that
a page visitor can sign in for the newsletter easily. I think to
register with a proper user name and password would put of users to
register for the newsletter.

greetings

Ron


Franz Holzinger schrieb:

> Hello Ron,
>
>> so best extension to use in my situation is fe_users and
>> sr_feuser_register?
>> Or do you recommend tt_address for my situation?
>
> You can choose among both tables. However if you want to use logged in
> FE users or a shop with tt_products then you should stick to fe_users.
>
> Franz
>

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi Andreas,

as far as I see, fe_users is a table firmly build in the typo3 core.
There is an system extension "felogin" that enables users who are stored
in the fe_users table to log in the front end.
Then there are some further extensions to allow users to register them
selfs.

greetings

Ron

Andreas Burg schrieb:
> Hello Franz,
>
> can't find fe_users in the repository. Where is it?
>
> Andreas
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Ron,

> which Newsletter-Extension would you recommend to use with fe_users that
> a page visitor can sign in for the newsletter easily. I think to
> register with a proper user name and password would put of users to
> register for the newsletter.

you can use sr_feuser_register for this. Then a user can subscribe
himself for newsletters.

Franz

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi Franz,

that looks like a pretty cool extension.
I'm just still wondering if it is possible to sign in for a newsletter
without user name and password.

greetings

Ron


Franz Holzinger schrieb:

> Hello Ron,
>
>> which Newsletter-Extension would you recommend to use with fe_users
>> that a page visitor can sign in for the newsletter easily. I think to
>> register with a proper user name and password would put of users to
>> register for the newsletter.
>
> you can use sr_feuser_register for this. Then a user can subscribe
> himself for newsletters.
>
> Franz
>

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Andreas Burg]

Hi Ronald,

> as far as I see, fe_users is a table firmly build in the typo3 core.
yes, I thought so. I was wondering, cause fe_users was mentioned as extension in
this thread.

In my case I've decided to use the combination of direct_mail(as newsletter
system), felogin (to log in), tt_address (to store the addresses) and
sr_feuser_register (for selfregistering of a user). I hope I'm getting no
trouble, for I'm not finished with configuration yet.

Andreas
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Andreas Burg]

Hello Ron,

> I'm just still wondering if it is possible to sign in for a newsletter
> without user name and password.

that would be great, to make it safe, only a captcha and a mail confirmation
would be necessary.

Andreas
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Andreas Burg a écrit :
> Hello Ron,
>
>> I'm just still wondering if it is possible to sign in for a newsletter
>> without user name and password.
>
> that would be great, to make it safe, only a captcha and a mail
> confirmation would be necessary.

This is possible when the additional extension sr_email_subscribe is
being used. However the address is then stored in tt_address.

Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Andreas Burg]

> This is possible when the additional extension sr_email_subscribe is
> being used. However the address is then stored in tt_address.

Thank you Franz, I'll try this.

Andreas
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi Franz, Hi Andreas,

thanks a lot for the good ideas. So it looks for me as the most
practical way to use:
1) sr_email_subscribe to allow web page visitors to subscirbe for the
newsletter. Their data then will be stored in tt_address
2) sr_feuser_register to allow web page visitors to become real page
users with rights for forum, commenting system, shop, ... Their Data
then will be stored in fe_users

I'm just confused, as it seems that it might happen that now double
entries are possible for people who signed in the newsletter and
therefore are stored in tt_address and who are web page users at the
same time. How are these two database tables merged?

Subsequent this questions arise:

1) Is there an extension to send a personalized newsletter to both, the
people in tt_address and fe_users at the same time without sending mails
double to people?
For e.g. I want to:
- send the newsletter only to people who live in Germany or have no
place specified.
- address the newsletter recipient with his name if it is specified,
otherwise just with a "hello"

2) Is there any extension that allows me to view and edit comfortable
from the back end all data that is stored in fe_users and tt_address at
the same time.
For e.g. I want to:
- know what information there is for Mr. xy,
- create a entire new person "Mr. xy",
- view all people who live in Germany, (which might be a very very long
list in my case)
- search for all people who attended a special workshop,
- add the information that someone attended a special workshop,
- update the address for a person
- create a new information field if there was a new workshop and mark
all people who attended this workshop

3) I want to display some information to some people in the front end.
For e.g. I want to show all "team members" on one page. I normally would
use something like "outputyourtable". But now which table do I take to
get the data from. tt_address or fe_users?

4) What extension would you recommend to import a huge list of
name<e-mail> in the data base?

I already searched around for a good manual to describe a "best
practice" for this tasks. But up to now I'm just more confused. There
are so many extensions and different concepts.

greetings

Ron


Dr. Ronald P. Steiner schrieb:

> Hi List,
>
> I'm setting up a larger web project and am looking for an extension to
> fulfill this tasks:
>
> 1) Storing and checking information of people
> - e-mail, address, name, photo, notes, attended workshop A / B / C / D /
> ....
>
> 2) Sending personalized newsletters to people who:
> - live in a certain country,
> - attended workshop A and D but not E
> - ...
>
> 3) Checking information:
> - who attended Workshop A and C?
> - what information is there for "name x"
> - ...
>
> What extensions could you recommend for this tasks?
>
> #### tt_address #####
> The "old" address database. The big advantage seams to me that there are
> a lot of extensions who base on it. So I could possibly realize a
> newsletter as required with direct_mail_subscription and direct_mail
> In addition there are lots of interesting extensions which could come in
> handy later like: rggooglemap, addressgroups, ...
>
> #### tx_party / wec_people / partner ####
> I am still confused which of this extensions is the most current. David
> Brühlmeier seems to started with tx_party. Then the "web empowered
> chruch" carried the concept on in wec_people. partner is now is newly
> updated by David Brühlmeier again. In general the concept of this
> extensions looks brilliant. I'm just wondering is one of this extensions
> a good alternative to tt_address? Which one would you recommend? How is
> your experience with this extensions? Is there an extension for sending
> personalized newsletters with data from one of this extensions? Is there
> a way to use other tt_address extensions with this extensions? Is it
> worth trying the "new" concept, or is it just a lot of hassle? The data
> structure of tt_address might be a bit old fashioned, but there are a
> lot of extensions for tt_address, which might overcome this problem.
>
> What do you think? What are your experiences?
>
> greetings
>
> Ron

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Oliver Klee-3]

Hi Ronald,

Dr. Ronald P. Steiner schrieb:
> I'm just confused, as it seems that it might happen that now double
> entries are possible for people who signed in the newsletter and
> therefore are stored in tt_address and who are web page users at the
> same time. How are these two database tables merged?

You can use my "dubletfinder" extension for this.


Oliver
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi Oliver,

thanks for your tip.
If I see correctly the remove duplicates option of "dublefinder" only
adds the categories of all entries to the one preserved, but not the
other information to this person.
In my case there might be quite a lot of information to the person
stored in tt_address. Then the person signs in for fe_users. Now all the
information already stored in tt_address for this person has to be
transfered / associated to / with fe_users. ... what if the person
cancels his fe_users account?
Necessary would be a more automatic procedure. There should be a way to
avoid double entries from the start and not always check for duplicates
and then remove them.

greetings

Ron

Oliver Klee schrieb:

> Hi Ronald,
>
> Dr. Ronald P. Steiner schrieb:
>> I'm just confused, as it seems that it might happen that now double
>> entries are possible for people who signed in the newsletter and
>> therefore are stored in tt_address and who are web page users at the
>> same time. How are these two database tables merged?
>
> You can use my "dubletfinder" extension for this.
>
>
> Oliver

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Bernd Wilke]

on Sat, 16 Aug 2008 13:03:58 +0200, Dr. Ronald P. Steiner wrote:

> Hi Oliver,
>
> thanks for your tip.
> If I see correctly the remove duplicates option of "dublefinder" only
> adds the categories of all entries to the one preserved, but not the
> other information to this person.
> In my case there might be quite a lot of information to the person
> stored in tt_address. Then the person signs in for fe_users. Now all the
> information already stored in tt_address for this person has to be
> transfered / associated to / with fe_users. ... what if the person
> cancels his fe_users account?
> Necessary would be a more automatic procedure. There should be a way to
> avoid double entries from the start and not always check for duplicates
> and then remove them.

you might keep in mind the local laws.
in germany (nice to talk in english between germans ;-) ) you are not
allowed to mix/merge the different datarecords until the user gives you
explicit allowance. And for newsletter-subscription a minimum of data has
to be sufficient. Therefore a newsletter subscription must be possible
with only an email-address and you are not allowed to check about
additional data (name, city, preferences, ...) from other data. [1]

that might be a little less comfort for login-users, but enables a
clearer separation. your example: deleting a login, but staying in the
newsletter.

you might mix these records in one table (fe_user) having unique email-
addresses (additional index key) storing the records for login and pure
newsletter in differnt pages. then you have to define behaviour on
deleting login-records.
But keep in mind about 'deleted' records: records deleted within TYPO3
are not deleted in mySQL. In this way a 'deleted' record can block a new
subscription as an email-address is present alas no active record is
available. Again the german laws: you are not allowed to hold these data.
these Records have to be deleted completely, so no reconstruction is
possible. [1]

BTW: in the same way no google-analytics (or similar) is allowed as long
as the user is not informed in a noticable way about the complete storing
[1]


[1] does anybody really care about these laws?

bernd
--
http://www.pi-phi.de/t3v4/cheatsheet.html
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ronald Steiner]

Hi Bernd,

thanks for your comment. Can you recommend any link that explains the
details of this law and how to deal with it?
As far as I observe most companies store the data of their customers. So
when you order again, they already have your address, bank account, know
what you bought in previous orders and if you payed the bill. - is this
illegal according to German law?

greetings

Ron



bernd wilke schrieb:

> on Sat, 16 Aug 2008 13:03:58 +0200, Dr. Ronald P. Steiner wrote:
>
>> Hi Oliver,
>>
>> thanks for your tip.
>> If I see correctly the remove duplicates option of "dublefinder" only
>> adds the categories of all entries to the one preserved, but not the
>> other information to this person.
>> In my case there might be quite a lot of information to the person
>> stored in tt_address. Then the person signs in for fe_users. Now all the
>> information already stored in tt_address for this person has to be
>> transfered / associated to / with fe_users. ... what if the person
>> cancels his fe_users account?
>> Necessary would be a more automatic procedure. There should be a way to
>> avoid double entries from the start and not always check for duplicates
>> and then remove them.
>
> you might keep in mind the local laws.
> in germany (nice to talk in english between germans ;-) ) you are not
> allowed to mix/merge the different datarecords until the user gives you
> explicit allowance. And for newsletter-subscription a minimum of data has
> to be sufficient. Therefore a newsletter subscription must be possible
> with only an email-address and you are not allowed to check about
> additional data (name, city, preferences, ...) from other data. [1]
>
> that might be a little less comfort for login-users, but enables a
> clearer separation. your example: deleting a login, but staying in the
> newsletter.
>
> you might mix these records in one table (fe_user) having unique email-
> addresses (additional index key) storing the records for login and pure
> newsletter in differnt pages. then you have to define behaviour on
> deleting login-records.
> But keep in mind about 'deleted' records: records deleted within TYPO3
> are not deleted in mySQL. In this way a 'deleted' record can block a new
> subscription as an email-address is present alas no active record is
> available. Again the german laws: you are not allowed to hold these data.
> these Records have to be deleted completely, so no reconstruction is
> possible. [1]
>
> BTW: in the same way no google-analytics (or similar) is allowed as long
> as the user is not informed in a noticable way about the complete storing
> [1]
>
>
> [1] does anybody really care about these laws?
>
> bernd

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination