Messages

  Entire forum

Auto Light Dark

English

And who would own the ticket created at split
Original ticket owner, author of the post, person making the split?

Thoughts on this.... 2.1, Future?

I'd say move this to 1.2 or later depending on how much was already done. I'm not seeing this as an entirely important feature tho others might differ. Ticket relationship which i believe is complete seems more ideal anyway.

throwing a nudge here.

Can we decide how to handle this or move it to a later release if its too complicated

How are we looking here? Assuming this is next on the list

I've split a few tickets now - I agree that there should be an option for the new ticket to be owned by the original poster or at least proxy on behalf of said person.
IE.... Bob creates a ticket, this ticket is public and other users are allowed to reply (not just staff) at some point Charlie posts a reply that is better suited as its own ticket <-- Splitting this ticket at Charlie's reply should have the option to make Charlie the owner or proxied on his behalf.

From what I see:
User POV is rather straight forward especially if they are only in 1 role and 1 dept
- Multi-Depts just requires them to think a little especially if they have different roles in different depts.
Staff POV should be fine as well, considering you'd more likely train your staff to use your Helpdesk
SD Admin, of course this you would only grant to someone you trust.

Site owners should find the ACP fairly well documented, otherwise they'll have to come here and let us know and from there we can get a better understanding of what really needs to be in the docs/faq... we can then work towards pushing that in a future version, especially if we're adding this in the KB system.

Which is why I'm willing to help... I doubt it needs to be too technical especially from a user standpoint and admin just needs to wrap their head around setting it up right.

True... its something I can do if I choose to (though most times I choose not to )

I'm willing to help with the helps docs whichever way we decide to go.

This I actually thought about after SMF's change... I don't really like the new format so much but I do get that it's much easier to maintain and streamline the help docs that way, so I thinking opening in a new tab/window to the docs here would be best. The popup isnt a bad idea though it has that 1 extra click.. {click-popup, click-go to SD}

Can this be changed to a future version until someone takes it on?
As SD evolves so would the manual anyway... its not a must have at the moment IMO I could be wrong of course

That does sound like the best option, I originally agreed with B when i 1st read this topic.

Currently changing the urgency level logs each change
Low->Medium->High->Very High->Severe->Critical and the reverse is true as well.

Because of how changing urgency is handled we cannot change from Low->High without logging Medium as well, nor can we change from Critical->Low without logging every stop in between. Something similar to the dropdown used for ajax assignments might be more ideal here.

While the current setup fool proofs urgency changes, I find that once you get the hang of SD, this will become impractical and being able to change to higher/lower urgencies in less clicks would be more ideal.

Logging this as a future enhancement, others' thoughts on this are welcome .

Option to preview a canned reply like previewing a post or ticket before submitting it.

I just came across this as I was creating a reply that is about 13 or 14 lines riddled with BBC, though the final output is only about 4 or 5 lines. I input BBC manually for the most part so at times I tend to mess the closing tag a bit or even outright forget it . Needless to say I'm using SD live now and someone had to point out that I royally screwed up 2 of the canned replies (not too bad tho, 2 of 11)

I figure this would be a nice enhancement in the future to preview the replies before making them active. Otherwise I'll find myself creating them in a post on my local tester first, which isn't a big deal anyway

Categories and Dept prefix a tickets title, and can make it crowded, so since the category filters are shown in the header block, would making whether to display certain categories as prefix or not make sense?

For example I would have the users fill out the appropriate cats on creating a ticket, I would want my staff to edit the ticket just before marking resolved and add another cat (a custom status)... but I would probably only display the cat from the user input and the cat from staff I would just use the filtering where necessary.

If this makes any sense it's certainly a future endeavor not 2.0 by any means.

Technically it's no big deal, it's just another possible placement to be factored in.

What bothers me more is user confusion. There are already 4 possible placements, this brings it up to 5, and I think it could be confusing to set up, though it's interchangeable so it's not like you're stuck if you get it wrong (it's soft to change, it only affects how and when it's queried, really)

EDIT: Stick it in the tracker for 2.1.

You'd have to make it a separate type of placement, though. There's nowhere else in the table to store it.

So you'd have:
* position as under ticket
* position as additional info box on the left
* use as ticket prefix
* use as ticket prefix but also a category
* use as a category but not a ticket prefix too