Mass Actions triggering at different times

-- HikaShop version -- : 2.6.1
-- Joomla version -- : 3.4.8

I have a weekly mass action that is set to occur at 7am on Fridays. This last week (March 4th) it occurred at 10:02am. Any idea why this would happen? Nothing has changed in the configuration.

Sorry - it was March 11th. I've updated the timestamp to 1457701200 in massaction_last_trigger_weeks to fix. In previous weeks it was triggering at 7am. It it normal behavior for the time to change like this?

This is still occurring - and now the mass actions seem to be failing all together.

The latest one that failed was this morning at 7:00 am. Our weekly mass actions are set to occur at 7:00am on Friday each week. The massaction_last_trigger_weeks value as of this morning was 1460721600 (7:00am CST 4/15). At 7:10 I ended up having to manually process the mass action.

Here is a log of the past weeks:

3/28 - successfully triggered by cron but at wrong time (18:42) manually reset massaction_last_trigger_weeks
4/1 - successfully triggered by cron at correct time (14:00)
4/8 - cron trigger failed, manually processed (14:59)
4/15 - cron trigger failed, manually processed (14:38)
(updated timezone in Joomla config to Chicago time)
4/22 - cron trigger failed, manually processed (7:08)

Any idea why this is happening?

Everything appears to be set correctly according to the docs. I regularly receive the cron reports (had it set to every time HikaShop is triggered) and visiting the Cron URL works fine. Tomorrow morning the 2 weekly mass actions (detailed in my other topic) should trigger by everything I am seeing - but then again, I thought the same thing last week and they failed. I will be monitoring in the morning to see if they trigger and let you know.

One other thing I just noticed. Earlier this week I manually set massaction_last_trigger_weeks to 1461326400 (7:00 am 4/22 Friday CT)

It is now 1461329885 (7:58 am 4/22 Friday CT)

I've manually changed it to 1461326400 again.

What is causing it to change on it's own? Having it 'slip' like this is causing all sorts of reporting issues.

Would setting the con up on my server allow us to have it execute at the same second each week? If the interval keeps slipping this way eventually the reports will occur later and later in the day. They need to hit the HR department in the morning. I would really like to avoid having to reset the database trigger value each week.

Hi,

Just to recap, mass actions on a time-based trigger need to be set up as a corn task on the HikaShop website?

I'm just trying to figure out why my mass action is not going off .

also, how would I set up the filtering so that only orders placed during the last day are exported? I've set up all of the other settings but want to make sure that the reports I'm trying to get aren't overlapping data.

I was afraid this would happen. After having this interval 'slip' for several months we reset the massaction_last_trigger_weeks back to its original setting. Our massaction report runs at 7am each Friday and pulls orders from the previous week (order_created >= {time}-604800). It then exports an excel document and emails it to a different department for fulfillment. By setting the massaction_last_trigger_weeks back from around 8am to it's original 7am we lost an order in the 7am to 8am window in the following weeks report (order occured at 7:44). This appears to be a major flaw in the system. I would strongly suggest changing how this massaction cron based system works to eliminate this 'slip'. Is there anything we can do to prevent this from happening each time we have to correct the slip?

I have created a workaround. Here is the updated massaction (but there are still problems):

Triggers:
Every weeks

Filters:
Order status = payment confirmed
order_product_code = REGEXP ^V...$ (All the product codes are formatted the same: Start with a 'V' and are 4 characters long. E.g. V100, V200, V300, etc.)
order_created >= {time}-619200 (Which is 1 week + 4 hours)

Actions:
Export csv file
Email the csv file
Change status to 'shipped'

Every time the weekly 'slip' gets close to 1hr I manually set it back.

This leaves around a 1hr window in which orders used to slip through the cracks. However, by setting the time to minus 1 week + 4hrs this gap is closed (and gives me a little slack). Since the filter only includes orders that have the 'payment confirmed' and the massaction updates the orders to 'shipped' when it runs I don't have to worry about it grabbing any incorrect orders.

However, the csv file is very cumbersome. If a single order contains more than one of the ^V...$ items (E.g. V100x1, V200x1) it includes duplicate rows for the order. Is there any way to have the csv only include one line per order?

I need to restrict it to products that have that specific product code format. I could also do it by product category. Is there another way of doing this that would make it one line per order.

I would be willing to hire you to develop what we need as a plugin or to simply add it to the core Hikashop extension.

Would it be easier to customize the reports section? I'm seeing 2 options to get us where we need to be:

Option 1:
Develop a plugin (or build the option into the core extension) to simply collapse the duplicate rows in our existing massaction reports (what we have been discussing). If we can accomplish this quickly it represents the simplest path to our goals.

Option 2:
The Reports in Hikashop allow us to grab what we need. However, it lacks any automation and the exported csv documents have so much extra information in them that they are next to useless.

Here are the features we would need to customize the reports:

1) Ability to pick and choose the columns exported in the csv
2) Ability to schedule these exported csv to be sent via email at a set interval (weekly)
3) Ability to update order status when the report runs (change 'payment recieved' to 'shipped' etc.)
4) Ability to print reports (would only apply to reports with charts and would export as a pdf)

#4 is a bonus item. Not critical. 1-3 would be necessary.

If you and your team are willing to develop either option1 or 2 let me know.