[SOLVED] more logic than anything

[l0ve2hat3]

I am designing a system that has "Tickets".  Someone submits a ticket and it get stored in the database blah blah blah...

 

I am trying to think of a way to handle recurring tickets. almost exactly like outlooks calendar.  But it doesnt make sense to prefill the database for every ticket in the future... that would be infinity...

 

Can someone help me out??

[trq]

I'm not an outlook user so a description of the actual functionality your after might help.

[l0ve2hat3]

Please see attached screen shot.  Its pretty self explanatory

 

[attachment deleted by admin]

[l0ve2hat3]

anything?

[bundyxc]

It's been a half hour, which isn't much time at all.

On top of that, it's about 11PM on the west coast of the two Americas, and about 8AM in most European countries.

 

That means that most people are either in bed, or are just rolling out of bed.

So please, for the love of God... chill out, and don't bump your thread if you don't get the answer to a very complex problem while most of our users are asleep. Thank you.

[Daniel0]

So please, for the love of God... chill out, and don't bump your thread if you don't get the answer to a very complex problem while most of our users are asleep.

 

Actually, don't bump at all unless you've shown some sort of progress or are able to provide additional information:

17. Users should not "bump" topics that are still on the first page of the forums. If you bump' date=' you [i']must[/i] provide additional information.

[roopurt18]

I don't know what that has to do with tickets.  Tickets are just numbers issued for requests, such as support tickets.  What you've shown us is a recurring schedule.

 

Anyways the simplest way to store those in a database is:

id integer primary key

schedule text not null

last_run_tmz datetime null default null

next_run_tmz datetime null default null

created_tmz datetime not null

modified_tmz datetime not null

 

id should be self explanatory.  created_tmz and modified_tmz are just used to keep track of when the database record was created and / or last modified.

 

Instead of trying to create a database schema to match all of the possible things you can do with recurring schedules, just use a single text column called `schedule`.  Store a serialized PHP object that holds the scheduling information within it.

 

When you insert a record, insert the serialized object along with the date and time of the next time it should run (this goes in next_run_tmz.

 

Then you set up a cron job / scheduled task to run a php script that queries this table for all records where NOW()>=next_run_tmz.  The records returned will be the jobs that need to run.

 

Run the job, update the last_run_tmz to NOW() and update next_run_tmz to the next time it should run.

[l0ve2hat3]

bundyxc thank you for bumping the post

 

I guess tickets was the wrong word to use... its really a job management system where technicians go on jobs and the call center enters/schedules the "tickets" or "jobs"... But i really didnt want to get into detail because it didnt matter.

 

roopurt18

 

that seems perfect... although what if someone looks at the schedule in the future... that job has not been created by the cron yet...

 

 

[roopurt18]

I guess it depends on how they're looking at it and what they expect to see.