EasyPopulate 4.0 Support Thread

[mesnitu]

hi
I've been looking into rewards points. Not sure if already exists in EP4, but if it doesn't , it looks not too complicated to do it, but :
Now that EP4 as all those notifiers, what it's the best approach in terms of logic and performance, to incorporate in the core, or use another class, auto load , etc... ?
In this case, it would only deal with ration for categories that could be attach to categories file, and products... possibly in the full export.


Best Regards

[mc12345678]

hi
I've been looking into rewards points. Not sure if already exists in EP4, but if it doesn't , it looks not too complicated to do it, but :
Now that EP4 as all those notifiers, what it's the best approach in terms of logic and performance, to incorporate in the core, or use another class, auto load , etc... ?
In this case, it would only deal with ration for categories that could be attach to categories file, and products... possibly in the full export.


Best Regards

What data is applicable to the rewards point system as it relates to products? Ie, what changes are made to the ZC database to support this added functionality. If the only thing really modified is the products table, then no code changes are required. Would simply add the products table field data to the user defined fields in the admin configuration.

[mesnitu]

I don't have the updated module, not sure if it is the same, but for what I see, related to products it's only one table, the rewards master, that uses a columns "scope" to define if it is a product or categories, and "scope_id" to relate those cats / products IDs, and the rest to place the rewards ratio.
But I just have a quick look, so I'm talking in the air.
But, for what I understand , if it's outside the "products" tables, the user defined fields, doesn't "work"

edit: There's a global reward ratio, and the categories can all use that one or have there own ratio, but if one doesn't have hundreds of categories they are quite accessible ... but for me, the products it's more significant. That's the reason the I thought on doing it

[mc12345678]

You are correct the user defined field is good for only products table data. To incorporate something like this where data is being populated in a single table, I would suggest creating an additional link on the main EP4 page using the notifier that is in line with options like full export, categories, attributes, etc. Before that would pull in any definitions needed at EP4_START. Would add a file type/name, export filelayout and sql would be addressed by the default:section of the filelayout module listening for the desired "filetype" then well, I've currently run out of steam on describing the remaining export, but there should be an existing appropriate location to address a "new" filetype export. Import would more than likely be similar to what has been done for bookx, but more than likely be using the primary key of the rewards module table rather than a specifc products_id or category_id.

That last part said, two file types could be created, one for products and one for categories, or maybe three to then have a combined style. The user then could choose which method is easiest for their work method and controls...

[mesnitu]

I was checking , and the Features File , on import using the 9 status doesn't delete the featured product.
Is there another way ? Or this is not implemented ?

tahnks

[mesnitu]

Actually the status 1 is not doing anything. And if a date is left blank I'll get the year 2036.

[mc12345678]

I was checking , and the Features File , on import using the 9 status doesn't delete the featured product.
Is there another way ? Or this is not implemented ?

tahnks

Actually the status 1 is not doing anything. And if a date is left blank I'll get the year 2036.

This back to discussions you and I have had about the specificity of EP4. It has to date worked with ZC as one would work with ZC except in large quantities. Are you able to change the status of a product from the featured section of the ZC admin? As for the date, changes had been implemented in the main product area, will take a look at the featured section to see what has or has not been done to account for the absence of entered data/more recent PHP versions, etc... The expectation of a non-date when populating the database is 0001-01-01. The result of 2036 is entering 0000-00-00 which I thought I had seen even that this could be a database setup issue of having a default of 0000-00-00... (Issue brought to light in upgrading to ZC 1.5.5 and sql needed to correct for some date fields in some tables.)