Global Product Notifications

[spacebiscuit75]

I understand that this feature is a notification preference. What is the difference between the two toggle states. Is this an on/off toggle or else is it a toggle between two different types of notificaitons?

I ask because in the account settings the products that a customer has notifications setup for are only shown with checkboxes to unset the association if the global_product_notifications is not 'true' in the customers_info table:

if ($global['global_product_notifications'] != '1') {
        $products_check_query = tep_db_query("select count(*) as total from products_notifications where customers_id = '" . (int)$customer_id . "'");
        $products_check = tep_db_fetch_array($products_check_query);
		...

This suggests to me there is feature enables by turning off Global Product Notifications, more than just disabling a feature?

Any ideas?

[♥ecartz]

It looks like there are two levels: 

1.  Notifications just on particular products.

2.  Notifications on all products (global). 

So what that code is showing you is the ability to select particular products for notification.  But that capability is not needed for customers who sign up for global notifications.  So on that page, you are enabling selective notifications because global notifications are turned off. 

It's also a bit confusing in that the newsletter also has two levels: 

1.  Specific product.  Everyone who selected global and everyone who selected that particular product. 

2.  Global.  Everyone who selected global and everyone who selected any product. 

[spacebiscuit75]

Thanks - I understand the notifications can be of all products or those selected by the customer, but what is in the notification itself - what is it notifying?

[♥ecartz]

It's under admin > Tools > Newsletter Manager.  You would define the notification yourself. 

The code which you posted is allowing people who did not sign up for global notifications to sign up for select products.  It does not, in and of itself, notify them of anything except the ability to sign up for notifications. 

[Heatherbell]

2 hours ago, ecartz said:

Notifications on all products (global).

I'm probably missing something obvious (as usual) but as a customer, I've personally never seen this used in any website (besides an osc shop).
Presumably it has an application that I cannot think of - what do others use it for?

[burt]

I have never seen "global notifications" used (and that is across hundreds of osc shops). 
It's very rare that the notifications system is used at all by any shopowners as it is difficult to use.

Global is to allow customer to sign up to ALL product notifications.
ANd then you have the usual "single product" notifications.  <--- this I have seen used

The single product notifications are signed up for by way of;

• notifications Box
  NOT installed by default
• checkout success Module
  IS installed by default

And then...unless shopowner does it manually..nothing ever happens... 

In the admin side you'll find the notifications system at Admin > Tools > Newsletter Manager
It is clunky and unintuitive and has had little (no?) attention in years (20?).

If you run this SQL in phpmyadmin;

select count(*) from products_notifications

this number is the amount of notifications in your shop, which is people asking to be notified about things.

[valquiria23]

3 hours ago, burt said:

It is clunky and unintuitive and has had little (no?) attention in years (20?).

Good idea to update in the next version of OSC, don't you think?

[spacebiscuit75]

So am I correct in stating that the global product notifications is an opt-in to receive a newsletter if one is sent va the admin. Only those customer who have this value set to true will receive the communication?

If this is the case, what if as a customer I want to opt-into this group AND also subscribe to individual products. I have noticed that if you choose to set global product notifications to be true then any enteries in the product_notifications which you may have set up are removed - this doesn't make much sense to me.

It would appear that the global_product_notifications field is not just an on/off toggle but is in fact a toggle between two distinct features, something that is not obvious or clear. In my opinion there should be two fields on the customer table, providing the ability to toggle between two distinct features.

[spacebiscuit75]

Ok so I think that I figured it out.

Product Notifications are a type of newsletter that can be sent from the admin: Tools -> Newsletter Manager. When sending this type of newsletter you must select at least one product.

- if 3 customers have opted in for Global Product Notifications all 3 they will be notified

- if 2 customers are not opted into Global Product Notifications but they have selected to be notified of this particular product these 2 will also be notified

Therefore a total of 5 recipients will be notified, the intersection of the two groups. I think that this is a valid feature just that it is not very clear and obvious. In my case I have updated the forms and labels to make it clearer to the customers, I've renamed it as "Product Follows" to give it more of a social media feel.

Many thanks!

[spacebiscuit75]

Further to the above findings - the product notification ignores the customers newsletter subscription setting on the customers table. So despite the notifications being sent under the newsletter feature this field is not used to filter customers to be included.

It is only used if the module/type option when creating the newsletter is set as "customers_newsletter" flag is used.

 

[♥ecartz]

10 hours ago, valquiria23 said:

Good idea to update in the next version of OSC, don't you think?

Is it more important than

1.  Allowing catalog display code to be used in admin?  So the store owner can, for example, register a new customer using the same features as are available on the catalog side. 

2.  Allowing store owners to choose what fields (including new fields) and in what order to show on the create account page? 

3.  Better install options for both the store itself and for Apps so that files can be uploaded without giving the web user permissions on folders. 

4.  Allowing more control over what pages require login and which don't so that Apps like Purchase without Account don't require core changes. 

5.  Adding more compatibility Apps for functionality removed from core. 

6.  Allowing store owners to make language specific configuration, e.g. a different store name in different languages.  Or different payment modules installed. 

7.  Making it easier for App developers to make modules that import or export data. 

8.  Allowing store owners to make template changes without changing core code and enable designers to make separate templates that don't need to change core code. 

9.  Better ability for App developers to turn off core functionality and replace it with custom functionality.  E.g. for KISS  IT Thumbnailer. 

10.  Make it so that order total and payment modules interact better such that a payment module based on line items (e.g. Paytrails) will automatically be updated when someone installs a new line item order total module (e.g. the Gift Wrap module). 

11.  Allow translators to export all the language defines into a single file, translate that in there, and then upload back to osCommerce. 

12.  Include the Option Type Feature in core (supports free text and image attributes). 

13.  Allow stock keeping on different variations of the same product while still allowing options that do not keep stock separately.  E.g. different sizes of T-shirts might be separate while custom embroidery would use the same stock. 

14.  Allowing notification methods other than email. 

15.  Simplifying the checkout process. 

Most of those are from my TODO list, although the first is something on which Gary is working and the last three are requested but not assigned. 

I would guess that there are far more store owners wanting to track stock on variations than there are wanting to send more emails from inside osCommerce.  Why?  Well, for one thing, there has been an App for such stock tracking since almost the beginning. 

And a newsletter manager is an example of something that would be relatively easy to implement outside of core.  Particularly the way that things are implemented now.  It's also worth noting that it isn't that hard to export the email addresses of customers who signed up for newsletters or notifications to an external mailing program with much better email handling. 

Anyway, my point is that if we were going to pick a large project, and updating the newsletter manager would be a large project, it would make more sense to update core to support tracking stock on variations.  As that is always going to require core modifications.  So better to bring it into core than force people to hack support on as an afterthought. 

It makes more sense to concentrate core development resources on things that have to be done in core than on things that can be released as Apps.  Because core development resources are limited.  And the truth is that a Newsletter Manager is exactly the kind of thing that could be implemented as an App.  In fact, I think I'll add "Migrate Newsletter Manager to App" to my TODO list as part of #5 in the list above. 

Unless a Newsletter App becomes overwhelmingly popular, that's not functionality that really needs to be in core.  Particularly as we've moved away from email subscriptions to things like Facebook and Twitter. 

[burt]

"Blue Widget" - 2 customers want notifications
"Red Wodget" - 5 customers want notifications
&
"Global" - 1 customer wants notifications

If you send an update about your Blue Widget, 3 customers will get it;  2+1 global
If you send an update about your Red Wodget, 6 customers will get it;  5+1 global

These notifications are accessed (to sign up or remove) at;
- a side box
- a checkout success module
- account_notifications.php

Newsletter is a separate system which works based on the "subscribe to newsletter" toggle in the create_account.php, it bears no relation to the notifications system. 

TL:DR;

Notifications:  about individual products [typical example:  "blue widgets are back in stock"]
Newsletter:  anything else

 

[valquiria23]

13 hours ago, ecartz said:

Most of those are from my TODO list

HELLO Matt

I love your list of proposed improvements, I hope @burt will takes it into account for future releases.

However, I understand that the improvement of the Newsletter system is also important since it is obsolete, and communication via email is still relevant for:

- Notify in advance closing for holidays.
- Promotions.
- Send new year's greetings

Obviously, only the owner of the circus will know in which order to take out each show, but it is good to contribute and inform in what the  observers are interested of .

Best regards.

Valqui

[joe122joe]

14 hours ago, ecartz said:

Is it more important than

1.  Allowing catalog display code to be used in admin?  So the store owner can, for example, register a new customer using the same features as are available on the catalog side. 

2.  Allowing store owners to choose what fields (including new fields) and in what order to show on the create account page? 

3.  Better install options for both the store itself and for Apps so that files can be uploaded without giving the web user permissions on folders. 

4.  Allowing more control over what pages require login and which don't so that Apps like Purchase without Account don't require core changes. 

5.  Adding more compatibility Apps for functionality removed from core. 

6.  Allowing store owners to make language specific configuration, e.g. a different store name in different languages.  Or different payment modules installed. 

7.  Making it easier for App developers to make modules that import or export data. 

8.  Allowing store owners to make template changes without changing core code and enable designers to make separate templates that don't need to change core code. 

9.  Better ability for App developers to turn off core functionality and replace it with custom functionality.  E.g. for KISS  IT Thumbnailer. 

10.  Make it so that order total and payment modules interact better such that a payment module based on line items (e.g. Paytrails) will automatically be updated when someone installs a new line item order total module (e.g. the Gift Wrap module). 

11.  Allow translators to export all the language defines into a single file, translate that in there, and then upload back to osCommerce. 

12.  Include the Option Type Feature in core (supports free text and image attributes). 

13.  Allow stock keeping on different variations of the same product while still allowing options that do not keep stock separately.  E.g. different sizes of T-shirts might be separate while custom embroidery would use the same stock. 

14.  Allowing notification methods other than email. 

15.  Simplifying the checkout process. 

Most of those are from my TODO list, although the first is something on which Gary is working and the last three are requested but not assigned. 

I would guess that there are far more store owners wanting to track stock on variations than there are wanting to send more emails from inside osCommerce.  Why?  Well, for one thing, there has been an App for such stock tracking since almost the beginning. 

And a newsletter manager is an example of something that would be relatively easy to implement outside of core.  Particularly the way that things are implemented now.  It's also worth noting that it isn't that hard to export the email addresses of customers who signed up for newsletters or notifications to an external mailing program with much better email handling. 

Anyway, my point is that if we were going to pick a large project, and updating the newsletter manager would be a large project, it would make more sense to update core to support tracking stock on variations.  As that is always going to require core modifications.  So better to bring it into core than force people to hack support on as an afterthought. 

It makes more sense to concentrate core development resources on things that have to be done in core than on things that can be released as Apps.  Because core development resources are limited.  And the truth is that a Newsletter Manager is exactly the kind of thing that could be implemented as an App.  In fact, I think I'll add "Migrate Newsletter Manager to App" to my TODO list as part of #5 in the list above. 

Unless a Newsletter App becomes overwhelmingly popular, that's not functionality that really needs to be in core.  Particularly as we've moved away from email subscriptions to things like Facebook and Twitter. 

will this list go to core? or it is just your TODO list