Staff CP -> Staff should not be able to see departments they are not assigned

[NC Software]

Staff belong to groups or are assigned specific departments. There are departments we don't want them to know about. Staff should not be able to assign OR SEE departments in which they are not assigned. They are not to know of their existence!!!

[Jamie Edwards]

Hi Neal,

I believe this is more of a feature request (for absolute privacy of a department where a staff is not assigned). I have moved your thread to the feature requests forum.

Thanks,

[NC Software]

No it's not, it's a heinous bug or mis-sight in the design of the application. If a staff member assigned a ticket to another staff member and a department in which the newly assigned staff member is NOT a member of, the ticket will be lost, potentially auto-close and a customer lost!

You MUST have a proper permissions and validation system that when a staff member is selected from the drop down list, only departments in which this staff is assigned should be displayed in the departments drop down list, and when you click submit, if the staff and department don't align (staff cannot work in the assigned department) the ticket assignment should stop, error raised, and allow a correction.

For the logged on staff member, they should not know of departments in which they are not a member of. This only leads to frustration "how come I can't get into..." and then they feel left out, inadequate, yadee yaddaa!

[Jamie Edwards]

Hi Neal,

How the system works now works and is suited by the majority of users - for example, if a ticket comes into StaffX's department but it is meant for another department to which StaffX cannot access. Rather than have StaffY "dip" into StaffX's department, StaffX has the ability to move the ticket into the other department without being able to look at tickets within it.

In order to completely remove a department from all staff view areas would require an additional feature (option), so I have classed it as a feature request.

[NC Software]

One of the more critical issues, still not handled, and 1-2 years later, I can assign John Doe a ticket to a department he doesn't belong! Let's say I have 20 departments, one of which is Consulting. I assign a ticket to J.D. and move the ticket to Consulting, it's in the drop down list after I select "John Doe" from the assignments. But guess what, J.D. isn't a member of the "Consulting" Department!!!!!

This again is the complete and total failure of user-interface design in Kayako Support Suite. I could go on with about 50 other items I have brought up along this line, they continue to fall on deaf ears! The only thing we gain by posting these issues is ARTHRITIS!

[craigbrass]

I think this is working to design but needs a bit of work on it. What needs to happen is a warning saying "Warning: The user you are assigning the ticket to is not a member of the department. Please be aware that they will not be able to see the ticket.".

[NC Software]

No - the way it "should" work, and Varun once upon a time said it was working this way "internally" but I have yet to see it is:

When you select a staff, the department drop down should dynamically load with the departments in which the staff is a member of. This prevents you ever from assigning a staff to a department in which they are not a member. Imagine an organization where you have a secretary that receives all tickets and assigns them out. He/She has no idea who is assigned to what department, this fictitious organization has 500 staff and 150 departments. I would love to say 5,000 staff but I think that is something Kayako is in no way designed to handle! But either way, filtering the department drop down to only departments the staff is a member of or throwing an error, something needs to "validate" to prevent unreachable tickets. There are numerous scenarios like this that have been brought to K's attention, continually ignored!

[craigbrass]

Ah yes, this is a much better way of working. AJAX could be used to load the departments that user is assigned to when that staff member is selected.

[Siora]

I would definately have to agree with this. Kayako needs to make better use of dynamic lists especially when it comes to custom feilds. if you could create custom feilds that dynamically change other lists it would be so helpful. IE. If I select MS Office from a list, the next list should automatically select all the office applications.

Anyhow, the problem mentioned here is a bigger issue that becomes more of a security problem for the internal users.

[richm]

I'm for this. The software should be filtering based on what you select. Good interface design makes software "intuitive" and shouldn't allow users (for the most part) to do things that make no sense in the flow of process.

Rich

[craigbrass]

Needs moving to feature requests really to get noticed for V4. Hopefully one of the mods will do it.

[PeteV]

That makes sense, however...

It does not seem to make sense that it is possible to assign a Ticket to a combination of a staff and a department, if the staff does not belong to that department. Then, the staff does not have access to the Ticket, and someone else will need to discover this and rescue the ticket.

This does seem more like a bug (in design, not code perhaps) than a request, or not?

[NC Software]

Totally missing the boat here, let's try Kayako 101:

Ticket comes in to the "General Department" and it is "unassigned", right?

Secretary Jane says "hey, this is for Tom to handle" so she assigns it to Tom, and thinks, "hmmm, I'll put this in the "Tier 2 Tech Support" department. Well, Tom is a rookie and is in Tier 1 Tech Support. So Tom gets a notification of a new ticket assigned BUT gets access denied when trying to follow the link to the ticket.

I really don't need to explain this now do I? We've been over this time and time again on this forum, it's "common sense" now take a step back and look at the system and see how you have staff and departments and if a staff is assigned a ticket and the ticket is in a department they are not assigned, you have wasted yet more company time due to bad design. The moral of the story is that the staff member Tom should have never been paired with "Tier 2 Tech Support" for the department as he doesn't have access.

We can take this one step deeper. We have private departments we don't want some people even knowing about. We have "Super Double Top Secret Skunk Works" for our "special projects" and we don't want Jane or Tom knowing this department even exists.

On and on, permissions are weak, for example, I want to allow my Staff to create Private KB articles but NOT Public. They can keep KB articles for their internal notes on how to do things but only certain people in the organization can publish PUBLIC KB articles. Once, again, common sense, the permissions system falls way short.

Bottom line, Kayako over the past two years has had their head more wrapped around finding office space and employees than developing software and WE are all suffering from this.

[PeteV]

I completely agree.

To be honest, eSupport generally does a good job with handling customer support requirements, if the staff is willing to be somewhat flexible. Afterall, you cannot please everyone, there is always the issue of priorities when developing an application, and bugs/shortcomings happen. That is certainly understood and accepted.

But this issue of invalid staff-versus-department combinations seems to be fundamental to customer support requirements. Afterall, "lost"/"unreachable" Tickets are completely unacceptable.

In fact, a proper customer support tool should NEVER remove any Tickets (and also other important information) EVER, without very explicit Administrator approval. .. but now I am off course...

Jamie, I am not complaining. We love your product. It just seems that you perhaps did not fully understood the ramifications of the current implementation, and I just wanted to back Neal up (not that he really needs that of course), since this is such an important issue.

Anyone else out there having the same concerns?

[NC Software]

I noticed in 3.11.01 that the Status List is dynamically populated when the Department is changed. This is good. Now you need to do the same for Owner - Department. When the Owner is changed the Department list should be dynamically loaded based on the Departments the Owner is a member of. Why this hasn't been done when you did it connecting Department to Status beats me!