Critical Bug: Department/Staff Drop Downs

[johnham]

Are you using 3.20.02. This fix only applies to 3.20.02.

[ecornet]

ah ok

[Jamie Edwards]

This bug has been fixed in the latest CVS build (what will be 3.20.03 stable).

[NC Software]

When this issue is fixed, which I hope is soon, be sure to:

1) If a staff is already assigned AND the staff is in the newly selected department, that staff should remain selected

2) If a new department is selected AND there is only ONE staff member in this department, automatically set that staff. There is no reason to leave it "unassigned" - one staff for one department, select the staff member.

[PeteV]

Dear Neal.

I respectfully disagree (I was watching "Friends" last night) with your last statement.

Even if there is only a single Staff member in a Department (besides Unassigned), then eSupport should not automatically select that Staff member per se (i.e., I am not sure that this is a "hard" fact).

In our organization, we have three reasons for not doing this per se. (1) We have a dynamic organization, and people move around all the time. Today, there could be only one Staff member in a Department, but that Staff member might be unqualified for that Ticket, and we are waiting to add another Staff member to that Department (at least temporarily). (2) We use Unassigned as an invitation for other Staff to volunteer (and then Administrators assigning the Ticket to the volunteered Staff). (3) We use Unassigned if a manager has not made a formal decision yet on how to handle important Tickets (for example, whether to assigned it to a different Department afterall).

Anyhow, I can see that assigning a Ticket in a Department with a single Staff member to that Staff member might be more frequent perhaps, but I am not sure that this should be the rule.

Thank for pushing this issue, Neal -- this is much appreciated on our side.

[NC Software]

I am talking about selecting the only staff member of a department when changing the department, i.e. making a selection from the department drop down, not when a ticket arrives. You could change it to unassigned but for most of us we need a staff set when a department is set. I have no reason to ever leave a ticket unassigned when moving it to a department, it needs to be handled. If you don't select the staff they won't get notification of the assignment yet they are the only ones that can view anything in the department anyways, so you are essentially orphaning the ticket now as it is moved but the staff is not being notified of its existence.

[PeteV]

... and now I respectfully agree.

Thanks, Neal.

[NC Software]

When is this going to be completed with testing and published in a STABLE release so we can use it? We don't use CVS builds, we need the fix ASAP.

Thank you.

[Jamie Edwards]

Hi Neal,

Still, there is no ETA - a release candidate will be released when ready.

[NC Software]

Status? We need this fixed!

[Jamie Edwards]

Hi Neal,

As always, you can view the progress on bug fixes in the tracker: Kayako Bug Tracker - Issue List

[NC Software]

LOL - I'm not interested in your ever monstrous bug list. I'm interested in the status of the next STABLE. You released a poor quality STABLE, let's get it resolved and a new STABLE out ASAP to end our suffering!

Thank you!

[Jamie Edwards]

Hi Neal,

As you know, we do not give out ETAs on our builds; we prefer to keep roadmaps flexible. As such, the best estimate you can get is one you make yourself by looking at the roadmaps; again, available in the tracker.

[NC Software]

It's unfortunate you don't have ETA's as you put out a poor quality product that needs an ETA to be fixed. It's not uncommon to put out ETA's such as "We expect the next stable in JUNE", etc. Instead, you are presenting your companies inability to plan development tasks properly. Kayako should mean "infinite delay" in some language around the world. We endured nonsense after nonsense regarding call centers, offices, etc. How about putting some professionalism into the software product and the quality. Either fix the glaring issues introduced in your last stable with hotfixes or release a new stable.

[John Haugeland]

Originally Posted by NC Software

It's not uncommon to put out ETA's such as "We expect the next stable in JUNE", etc.

Neal, we don't put out ETAs. Period. We don't put ETAs out because that way, if a bug that cannot be postponed needs to go into the current plan, then we don't get yelled at by a bunch of people who expected us to hit an estimate as if it was a promise.

We're not giving an ETA.

Originally Posted by NC Software

Instead, you are presenting your companies inability to plan development tasks properly.

No, we're remaining flexible and retaining the ability to change as situations demand. It is unfortunate that you disagree with our company policies. However, they remain our company policies.