Quote:

Yep, you are
From expirience: there are times you want to manage lists which are not limited your your site users.
Sometimes you had a previus site and need to import (csv) your customers into your new XOOPS site (best way will be to email them with your (new) newsletter app and invite them to register @ your new site
So, this is about using your users-profile from Xoops.
And don't forget that you need to import your users to the mailinglist anyway, so why not expending it to your needs - with the ability to use the data in the mails you send ...

I'll give a simple example: you has your mailinglist, groups and all, and want to send a personallized mail just to dog owners, so your mail will have the header
"hello < - Dog owner name - > , bring < - Dog name -> to the vet ... "

I am now in the process of converting 2 existing local communities into Xoops, and I definatly see the need, not the need for just another mailinglist, but for a heavy-deuty one, and if you already has your lists (divided to groups), why not using them for presentation too (like an addressbook or phonebook) - then you'll "catch 2 birds with one shot"
I saw a lot of requests for a decent phone book in here in the past years, and my logic say that it will be very wise to combine the two and not to end up with 2 modules you wish were one ....

I'm using phplists for years and I missed those features ...
I use it's custum fields ability with my customers a lot, giving me the option to personalize my emails and helps me insuring they won't delete my mails as a "mass mails"

Still not convinced.

What if the "membership" module was expanded in capability.

So that you could include unlimited custom fields. Deciding which were optional and which were mandatory.

And what if the membership list was tied to the newsletter mailing list subscription categories.

And subscription categories were tied to groups.

In this case your user could "register" on the XOOPS site, provide their name, their desire to be on the "dog" list, but not the "cat" list. Or none at all.

You then target a dog newletter to the "dog" list and insert XOOPs membership profile data into the email automatically.

And what if you could batch import users into the membership list, giving them the ability to opt-out if they so chose.

Then users could control everything themselves, XOOPS notifications, newsletter subscriptions, etc from their profile.

If you are going to have a separate database structure for the contact list (that's not part of the membership module) why bother making it a XOOPS module at all? Why not just use an external solution like bMail, PHPList, etc. There are a zillion external, stand alone mailing list options to choose from.

Scratching my head...

Quote:

I agree andy, but it's not a "What if" situation .... things are moving quite slow lately @ XOOPS and if you want to wait till the "What if" will be cleared ... you'll wait at least 6 monthes to my estimation - till the new 2.4/2.4 series will get into beta and RC and a few 2.3.1 ... 2.3.2 .... debugs versions and so on ....
If you ask me ... THIS IS THE SOLUTION - an enhanced profiles module that will replace the existing one ....

But !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I want to be able to have in my mailinglists peoples that are not XOOPS users and that is what guide me ...... why should they be forced to be registered ... how will I import them into the "profile" module if they are not registered? .... what password will they get from the system?
Read Skalpa's post about scalebility of OpenSource and XOOPS - the direction it's going to - is to separate tasks/modules/etc' .... I want a strong (very strong) tool that won't be limited by the system (Xoops) , but will be using it's advantages , and will serve mu needs with the upcoming versions ...

I see it as a stand alone mailinglist that will "know" how to work with XOOPS users database but won't be limited to it !!!!

Lets get it moving .................... I need to know the directions .... and the cost ....

Hi, allow me to take position here. I agree with Andy. I don't beleive we need a separate table to hold users information. The xoops_users can do the job perfectly.

Quote:
Why ? If you I want to be subscribed to your mailinglist AND be a registeted member of your site, why would I need to complete 2 registrations ? Only one should do the job. We could customize the way users are added to the site in different ways to allow someone:

- to be a User AND a newsletter subscriber
- to only be a User
- to only be a Newsletter subscriber

For the user, it will be transparent, but in the background he will be manage as a User of the site. For him, it makes no difference.

I can see the registration form of the site where, in addition to register as a member, you select the different newsletter you wish to subscribe to.

In the other hand, I can see the Newsletter subscribe form as simple as entering an email + checking the newsletter you want to subsribe to. Hit Go, and that's it.

In the background, the system would create a new user, assign him a password, subscribe him to teh newsletter and send a beautifull email explaining everything : you are now subscrive to our site, here is your password, here is the page where you can customize your newsletter preferences, etc...

Quote:
Absolutely. But why separate informations about the very same objects. Registered users and newsletter subscriber can really be see as the same object : a person. So we need to manage both of the in the same manner, with a few properties that difference some behavior.

Quote:
If this is really what you want, then I beleive the best way is to hack your favorite newsletter code and only hack a little part of the system to hook newsletter users to XOOPS users. And I beleive this can easily be done.

However, I don't think this will reach the objectives that Andy and I had in the first place. But perhaps this could be an "easy and cheap" solution that could do the job for certain needs.

Thoughts ?

Thanks for keeping the conversation moving.

Following is a proposed features list for an integrated newsletter module for XOOPS 2.0.13.x

One minor question is whether or not to put any effort into the ability to send newsletters in both text and html format, or in multi-part mime.

My feeling is that almost all current email clients are HTML capable, so we should not bother with offering a preference or text only options. Just send HTML messages. It will simplify things a bit.

SmartFactory is working on developing an estimate to build a newsletter module based on the below features.

Subscriptions/List Options
Integrate with XOOPS membership module
Support multiple mailing lists (categories) unlimited number.
Ability for users to opt-in and opt-out of subscriptions
Ability to batch import email with a default password(?) via cvs
HTML//Text preference (optional feature. Maybe we just do HTML)
Language preference(?)
Support for hidden lists
Support for closed lists (based on subscriber count, or admin control)

Membership Module Expansions Required
Additional custom (admin defined) fields. See alternate membership module. What’s required, optional etc.

Public View of Newsletters
Auto Archive – view permissions controlled by XOOPS groups
Printer friendly format
Email to a friend
PDF creation
RSS feeds

Authoring
Templates for publishing, (header, footer)
Default template for each list
HTML editor.
Text version of content (auto generated,with manual ability)
Authoring (Submit) permissions controlled by XOOPS groups
Set date to publish/send (future issues)
Content fields: Title, date, issue, volume, summary, body, file attachment, Option to have the “read more” be a link to the full article on the XOOPS website, instead of in the email sent.
Ability to include XOOPS variables (member field info) in newsletter to personalize.

Sending
Select list to email message to
Subscription list over-ride (send to all lists)
Send in packets (admin defined) – batch quantity and pause interval, batch and throttle.
Auto resume if sending fails at one point
Ability to pause, resume, cancel mailing in progress
Open tracking
Send multipart email messages (text/html) – (Optional, maybe we just do HTML)
Bounce tracking – count, threshold to remove from subscription.
Auto-responder for automatically sending pre-defined messages at set intervals based on subscription sign up date

Admin
“Display in archive?” has (admin) control by individual newsletter issue.
Subscription list management – add, edit, delete, search, view, bounce monitoring
Archived message block display control – sort by weight, sort by date. Limit number displayed.

XOOPS Integration
Membership Module
Multi-language capable(?)
What’s New module plug in
Blocks – subscribe, recent issue, categories, etc. Need some more info here.
Opt in preferences (single or double) is controlled by XOOPS user pref. If already a XOOPS member, no need to opt-in

Quote:

OK, got convinced !!!
Though I just hope there's a Alphabetic sorting panel hack, as I need this group presentation alongside the mailinglist functionality.

Having now read through this topic, there has been so many options, use existing modules, develop a new module, etc,etc.

What is the plan ? Has there been any concensus, or I am I just reading the replies incorrectly ?

My initial enquiry was from this - https://xoops.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=49677&forum=4

P

Greetings to all you,
That happen? and you made me read these whole topics for anything. I cannot believe it.

Somebody could report that I happen, or exists somebody it working on the project?

At the end of this, exists some modulate to send html email.?

Ragards,
David

Greetings to all you,
That happen? and you made me read these whole topics for anything. I cannot believe it.

Somebody could report that I happen, or exists somebody it working on the project?

At the end of this, exists some modulate to send html email.?

Ragards,
David

Greetings to all you,
That happen? and you made me read these whole topics for anything. I cannot believe it.

Somebody could report that I happen, or exists somebody it working on the project?

At the end of this, exists some modulate to send html email.?

Ragards,
David