SiT! Bugs - SiT!
View Issue Details
0000580SiT!triggerspublic2009-03-23 21:432009-08-16 14:40
timfederwitz 
kieran 
normalminoralways
closedfixed 
3.45 
3.503.50 
0000580: Auto-assign Incident is not working
I put this under triggers because I believe this has something to do with that... however, I am wondering if it could be because my scheduler is not running?

From this area http://sitracker.org/wiki/Scheduler [^] I saw that you need to create a cron job for auto.php in order for the scheduler to run. I have not done this because I didn't know if I needed to or what it is used for.
No tags attached.
Issue History
2009-03-23 21:43timfederwitzNew Issue
2009-03-24 09:35TomseNote Added: 0000799
2009-03-24 22:07timfederwitzNote Added: 0000809
2009-03-25 11:48ivanNote Added: 0000811
2009-03-25 11:48ivanStatusnew => feedback
2009-03-25 13:10timfederwitzNote Added: 0000813
2009-03-25 13:50ivanNote Added: 0000817
2009-03-25 13:50ivanStatusfeedback => assigned
2009-03-25 13:50ivanAssigned To => ivan
2009-03-25 14:01timfederwitzNote Added: 0000818
2009-03-25 14:03ivanNote Added: 0000819
2009-03-25 14:06timfederwitzNote Added: 0000820
2009-03-25 14:08ivanNote Added: 0000821
2009-03-25 14:33kieranNote Added: 0000822
2009-03-25 14:33kieranAssigned Toivan => kieran
2009-03-25 14:33kieranStatusassigned => feedback
2009-03-25 14:53timfederwitzNote Added: 0000824
2009-03-25 14:56ivanNote Added: 0000826
2009-03-25 14:59timfederwitzNote Added: 0000827
2009-03-26 17:46timfederwitzNote Added: 0000843
2009-03-27 16:21timfederwitzNote Added: 0000847
2009-03-27 16:49kieranNote Added: 0000848
2009-03-27 16:49kieranStatusfeedback => resolved
2009-03-27 16:49kieranResolutionopen => fixed
2009-03-27 16:49kieranFixed in Version => Current SVN
2009-08-15 21:31ivanTarget Version => 3.50
2009-08-16 13:15ivanFixed in VersionCurrent SVN => 3.50
2009-08-16 14:40ivanNote Added: 0001749
2009-08-16 14:40ivanStatusresolved => closed

Notes
(0000799)
Tomse   
2009-03-24 09:35   
You need to create the cronjob with auto.php on the computer running your site.
so you DO need to set it up.. here is why..

a web application cannot run a scheduled job by itself. It is not directly part of the operating system and compared to the OS the web application are static files just as e.g. word documents.

So in order to make a scheduled job, it needs help from the operating system.
Thus creating the cronjob to run every minute you can schedule jobs in the web application.

Does it make sense ?
(0000809)
timfederwitz   
2009-03-24 22:07   
I created this on my site, so I will be able to see if this resolves my problem the next time a contact submits an incident. I didn't see anything in the auto.php script that signified to me it was assigning incidents... but I'm still so new to PHP and it looks like gibberish to me still (lol).
(0000811)
ivan   
2009-03-25 11:48   
Auto-assign doesn't use the scheduler actually, the assign happens just after the incident is created.

Can you post the steps to reproduce this? I suspect this may be something to do with your particular set up rather than a bug. But I'm willing to be proved wrong ;)
(0000813)
timfederwitz   
2009-03-25 13:10   
Ivan, thanks for letting me know it's not a scheduler / auto.php thing. Makes me feel like maybe I *am* starting to understand PHP a little. ;)

I assume that the default install is setup to auto-assign any incidents opened by contacts. I verified that the auto-assign setting is set to TRUE. I login as a contact account, create an incident and logout. I setup triggers to send me email as soon as an incident is created, that is working. I have waited days on some tickets and they never get assigned. They are still assigned to the application name (RTPS in my case).

Is there a trigger that is supposed to initiate the auto-assign? Is there something else I can look at? I'm willing to give you access to my site to figure this out (it's not my production install, so no worries). You can PM me at tim-at-realtwistedpair-dot-com.

Because I had to get a production site up for my customer to start using, I decided to have them hold off on creating incidents until I can figure this out, and I am creating the incidents instead. This is mainly because the incidents need to go against a pool of incidents on a contract, and that ALSO isn't working on my test site if a contact creates the incident (it shows it is for that contract, but the incident is never charged against the pool of incidents unless I create it as a user - I submitted this topic to the forum and never got an answer on whether this is supposed to be like this) http://sitracker.org/forum/viewtopic.php?f=4&t=1416752 [^]
it is the last post under your reply... mid post is where I ask the question.

I just wanted to say that I am loving your application and the support from the SiT! team and the community has been outstanding!! I hope that I can get to a point in the near future where I can start to give back to this project and community!! Thanks for all of your help so far!
(0000817)
ivan   
2009-03-25 13:50   
Glad you're liking SiT, even though you've had problems! good to hear! :-)

I don't think portal incidents get auto-assigned, I think it's only incoming emails at the moment. I don't have time to check at the mo, but I'll leave this open and have a look when I have a few minutes.
(0000818)
timfederwitz   
2009-03-25 14:01   
Ahhhhh... that would make sense. ;-)

Okay, I *think* I'm starting to get that there are some substantial differences between the customer portal and the user's interface. Would this then fall in-line with why a customer contact creating an incident against a contract with limited incidents is not not being charged against the incident pool of that contract?
(0000819)
ivan   
2009-03-25 14:03   
Yeah it would, that one sounds like a separate bug, another thing I've not had time to check out.
(0000820)
timfederwitz   
2009-03-25 14:06   
do you want me to submit it as a separate bug?

I am using a workaround on that one where I simply create a new incident as a user and relate it to the incident opened by the customer contact. It at least provides the history from the original and then charges against the pool.
(0000821)
ivan   
2009-03-25 14:08   
Yes please. For now that would appear to be the work-around. I suspect there a few more bugs relating to incident pools to be honest, a lot has changed in those areas and it is a little-used feature.
(0000822)
kieran   
2009-03-25 14:33   
I've added auto-reassign for portal incidents in svn, however it could use some testing.
(0000824)
timfederwitz   
2009-03-25 14:53   
Okay, I will submit that as a separate bug. Just as an FYI, the incident pool feature of contracts was literally what made me decide to go with your product! :-D

The type of business I do has a lot of support contracts with a limited number of incidents over a limited period of time in a pre-pay fashion. Before your app I was trying to track all of this via email, and it was cumbersome at best and the customer would raise questions on how many incidents were left, etc.

Once I saw this feature in your product I was ecstatic! It will be SOOO easy for me and my customers now to keep track of things... and the customer is very excited about this feature too!
(0000826)
ivan   
2009-03-25 14:56   
Tim,

Pester us if it's not working as advertised then ;-) Well, log bugs for us to ignore anyway ;) (joke)

Ivan
(0000827)
timfederwitz   
2009-03-25 14:59   
LOL! Will do... I'm still loving your product!
(0000843)
timfederwitz   
2009-03-26 17:46   
Ivan, I created a customer contact for myself to play around with things a little more. When I created a ticket from the Customer Portal and submitted it, it displays a screen for a couple seconds that has some errors on it. I grabbed a screenshot, but it shows some of my server paths that I'd rather not post openly.

If you think it would be helpful to you, I can send it to you. Just let me know where to send it (email me at tim-at-realtwistedpair-dot-com).

The errors refernce triggers, some files and line numbers.
(0000847)
timfederwitz   
2009-03-27 16:21   
Just posting an update on my last post about the trigger errors I was seeing on the customer portal after customer creates an incident.

The errors were in fact the triggers I created myself and never set rules for them. After reading the documentation page http://sitracker.org/wiki/Triggers [^] (thanks Ivan), I realized I had to set a rule for the trigger.

Since I have done that, there are no more errors! (Yay).

However, the reason I opened this bug for, incidents not being automatically assigned, is still the case. Incidents are not getting automatically assigned.
(0000848)
kieran   
2009-03-27 16:49   
There's another bug report for that trigger error. Auto-assign has been added in svn so I'm going to close this bug, thanks for the report.
(0001749)
ivan   
2009-08-16 14:40   
Released in 3.50rc1