Yeah this seems to work

While testing this, I discovered a "thingy" that causes all issues to be processed when our CLI script runs...
04d2943
This has been modified multiple times to fix one bug after another and currently the last modified date is always overwritten...
@todo....

Can you look also on this PR please #592

While testing this, I discovered a "thingy" that causes all issues to be processed when our CLI script runs...

Hmm... How to avoid it? CLI and not CLI are using the same class. Should we pass some kind of parameter or flag to determine who is acting?

Should we pass some kind of parameter or flag to determine who is acting?

I think we should not set the last_modified_date in the store method at all... Do you remember the places where it is used by "non CLI" code?...

Exactly not, but think that in issue add, save and edit.

@allenzhao added a commit message stating a fix of a modified_date bug in dfbb4a5 when he added a check for a db null date but I can't remember what that bug was :(

Also... I feel like something wrong happens here: #427

It seems that we have many places where modified is set :)

I think we are using the last_modified_date from GitHub for issue comments and the date/time on our server for the activities, so I believe there might be a wrong time zone setting here that causes #427 - maybe...

@mbabker how often does the cron job run? I've made a comment here more than one hour ago and then deleted it, but still it is not deleted on the tracker.

All I'm going to say is it helps when the code is deployed live (that commit was merged on a weekend I was traveling, forgot to sync up when I got back)

glad that it is working after all

Great stuff
On 30 Jan 2015 13:55, "Dmitry Rekun" notifications@github.com wrote:

glad that it is working after all [image: ]

—
Reply to this email directly or view it on GitHub
#595 (comment).