Errors in "error_Log" file

[supportskins]

You need to change error_reporting to:

error_reporting = E_ALL & ~E_NOTICE

[Dynadata]

I know those errors would proberly be gone if I changed that setting but why does Kayako give me those errors?
There must be a reason for it, right?

[supportskins]

Create a ticket with Kayako Support and their developers should be able to assists you with it. You can create a ticket from http://members.kayako.net/

[eger]

Also having this issue. I am not going to change my error_reporting just because Kayako spits errors.

Has a bug report been created for this?

[Dynadata]

No I don't think so. Hope Kayako will still fix this so I don't need to change my error settings again....

[eger]

I created a bug report for it: Kayako Bug Tracker - Viewing Issue #549 - Fatal Errors thrown in error_log need to be resolved

Looks like it started happening after the 3.20.02 upgrade for me also.

[efisher]

Originally Posted by supportskins

Create a ticket with Kayako Support and their developers should be able to assists you with it. You can create a ticket from http://members.kayako.net/

Anyone find an answer for this? I just noticed this myself whenever I turn on the loginshare for my template.

-Eric

[supportskins]

Eric,
What are the errors that your error_log is reporting?

[efisher]

[Mon May 12 22:41:37 2008] [error] [client X.X.X.X] PHP Fatal error: viewticket action is not registered in /var/www/html/support/includes/functions.php on line 742, referer: https://domain.com/support/

[eger]

They are saying they can't reproduce in the bug tracker: Kayako Bug Tracker - Viewing Issue #549 - Fatal Errors thrown in error_log need to be resolved

So I guess all these sites also have to just live with it...

[Jamie Edwards]

Hi there,

This 'bug' is actually a symptom of something else which we are going to investigate. The bug entry has been changed to 'Investigating' for the meantime (rather than opening another).

[John Haugeland]

Originally Posted by eger

They are saying they can't reproduce in the bug tracker

... and I asked you in the bug for more information. Can't reproduce means "we don't have enough data to make this happen." Doesn't mean "the bug doesn't exist." I set it to Can't Reproduce because I wasn't able to reproduce it. I still have a list of things that might be bugs that I don't have enough data to track down, and that lets you know that I need questions answered by you.

Basically every time I've seen this in a client desk it's been due to a partially completed upgrade. I've never seen anyone have this problem except right after an upgrade. We've been doing some talking internally about the problem, but we haven't come to a decision yet, so I'm not willing to talk about our current stance on the situation.

Please understand that when a developer puts your bug on Can't Reproduce, they're not turning you down, they're just letting you know that they don't understand the situation well enough yet.

And, look, maybe you should re-upload the files from the new version. You don't need to use the upgrader again, but personally speaking, every time I've seen this it's been because someone has several files from a prior version of the helpdesk lurking around, because maybe their FTP transfer got interrupted and didn't resume or whatever, who knows.

Am I saying that'll fix it? No: I don't know enough about the situation to understand the problem. But, y'know, it's one possibility, it's pretty harmless if you haven't modified your desk's code (and if you have, you should be telling us that), and hey, it's worth a shot.

No promises, right? But between you and me, I'd put a dollar on it.

If that doesn't fix it, please go back to the bug and give us as much information as you can. We're not ignoring you. However, as the old robot tradition goes, in a good old fashioned Majel Barrett voice, "insufficient data to analyze."

Seriously, right down to the color of the case of the machine it's running on. Details are important. Pretend you're on a medical diagnosis drama, and the writers are trying to stump you.

But try uploading the whole suite again (obviously be careful about the config file and so on.) You know, because tea leaves and chicken bones are awesome.

- John Haugeland
Kayako Development Staff

[craigbrass]

Gotta love the way John likes to post long posts when he occasionally comes here

I totally agree with him though. Developers can't be expected to wait for clients to provide information forever and delay the next stable build.

[John Haugeland]

Originally Posted by craigbrass

Gotta love the way John likes to post long posts when he occasionally comes here

Huhu. I'm a loudmouth and I type fast.

On a more serious note, I've found that a big chunk of customers are happier when someone takes the time to write them in detail, and really makes an effort to address what they've said. Sometimes people think of brief answers as either flippant or disrespectful.

This guy is unhappy because he's suffering through an apparent defect. It's important to me that if I can make him feel like we're taking care of him, that I do. This is the best way I know how.

Which really just means I'm no good at people, but hey, that's neither here nor there.

[John Haugeland]

Still no contact from original bug filer. Need access to a system exhibiting these defects to track them down.

Anyone among the people asking for a fix could be the person to help make it happen.