Critical Bug: Department/Staff Drop Downs

[NC Software]

Kayako,

I'm extremely disappointed AGAIN with your complete failure in testing and Q/A. Please fix this critical issue immediately and post a new stable build. This is completely and utterly unsatisfactory.

Select STAFF, select Department, STAFF goes back to unassigned. See attached animated GIF.

Standing by for immediate FIX!!!!

[NC Software]

When you change a department - IF the selected staff is a member of the new department selection then the staff drop down should NOT reset. That's the mistake you're making by not "setting" the staff drop down with the existing selection from the list if the selection validates on the new department selection.

[Jamie Edwards]

Hi Neal,

Thanks for pointing that out.

This is indeed a bug, albeit a cosmetic one (and not a high priority bug). The functionality the AJAX drop-downs bring is still robust and still solves the issue of hidden tickets when the assignment and department do not align.

When you encounter what you believe to be a bug in future, please post it in the tracker: Kayako Bug Tracker - Issue List

Regards,

[Jamie Edwards]

Bug fix targeted for the next stable: Kayako Bug Tracker - Viewing Issue #491 - Staff assignment cleared on dept. change even when staff is a member of that department

[NC Software]

This is indeed a bug, albeit a cosmetic one (and not a high priority bug).

When I have a user selected, select a department and click submit and then realize it wiped out my user assignment, it is NOT cosmetic.

Have this issue fixed by Friday close of business and available either via hotfix or new stable release.

Thank you.

[Jamie Edwards]

Hi Neal,

Unfortunately we will not be able to do that. I will notify you once the bug has been fixed (I suggest you subscribe to the entry in the tracker).

Regards,

[NC Software]

So how did this problem get past both beta and release candidates? Was there no one testing? I thought you actually had semi-paid testers? This is why you should also, like vBulletin, use your own betas and release candidates on your own site before releasing, this should have never passed even the basic levels of testing. This simply does not pass the common sense test and I hope you all will finally do something about it to prevent this again. Just like I've said over and over, remove the config.php from your install and name it, like vBulletin, config.php.new so that when people apply updates they don't overwrite their config.php file. Does this pass your common sense test? This is yet another sign of a total disconnect between you and your customers.

[Jamie Edwards]

Hi Neal,

This was simply an omission on our part during testing, for which we're sorry - but these things happen. It has already been put in the tracker, has already been roadmapped and will be dealt with.

With regards to improving our testing; the developers and I are working on overhauling our testing procedures; investing into both automated testing procedures as well as manual.

We are also going to be changing our release schedules (as in implementing more regular ones) with stringent testing regimes for each - involving on our part manual and automated testing as well as encouraging further community testing (yes, like vBulletin has been doing). The feedback received during the release of the recent Release Candidates has been great.

config.php renaming: Kayako Bug Tracker - Viewing Issue #493 - config.php should be renamed to make upgrading easier

[NC Software]

This bug is affected in other areas such as ticket reply as well - FYI.

[Jamie Edwards]

I've noted that in the tracker entry.

Thanks,

[NC Software]

When will this issue be fixed please?

[Jamie Edwards]

Hi Neal,

Over the next few weeks. It has been roadmapped for 3.20.03, and the roadmap is unlikely to be downsized.

I spent the Easter weekend roadmapping the upcoming releases, so please forgive if they seem unworked on as of yet - we are working on them now. You can see the roadmaps here: Kayako Bug Tracker - Roadmaps

[welch]

Well, i found some of the problems and have attempted to fix this bug myself. I notice on the admin_ajax.php on 99 is where you pass the staffid into the function generateTicketAjaxSelectBox. However, on the recall it is displayed as ownerstaffid=[object%20HTMLSelectElement]

If you can give me a couple days, I can look into it when I get some time to figure out what is going on.

[johnham]

open
/themes/admin_default/main.js

goto line
3280

replace it with this line

loadXMLHTTPRequest(swiftpath+"staff/index.php?_m=tickets&_a=ajax&action=departmentstatus&formname="+escape(formname)+"&randno="+doRand()+"&ownerstaffid="+staffidfield.options[staffidfield.selectedIndex].value+"&departmentid="+departmentfield.options[departmentfield.selectedIndex].value+"&ticketid="+ticketid+"&ticketstatusid="+ticketstatusfield.options[ticketstatusfield.selectedIndex].value+"&sessionid="+swiftsessionid+"&fieldname="+selectname+"&prefixname="+prefixname);

basically the ajax request was passing the staffidfield object instead of the value of the currently selected staffidfield option.

so I changed

staffidfield

to

staffidfield.options[staffidfield.selectedIndex].value

I'll update the bug tracker with some notes on the fix.

[jnet]

well I think I have to work on it too.