This is something we don't have in 1.0 that in hindsight possibly should have been added, but I'm really keen that we should put this in 1.1.
Sounds good. I get people asking for support in Announcements and in other peoples topics asking for random help. So I get the idea this will come in very handy, at least for me.
Really this one is about keeping a ticket on course for what it is.
Some questions of relevance:
* Permissions? Own/any or just 'can split' and 'can merge'?
* For merging, require that both tickets are from the same person?
make sure you take deleted content into consideration
I basically can't forget it. The way the system is designed and the way the merge/split pretty much has to work doesn't allow me to forget either.
what if you are going to split previously merged tickets? do you have a way knowing where all the attachments goes?
*nods* Attachments are stored both against a ticket and an individual message, it's possible to keep track of exactly where it's supposed to be. The moment a split or merge is done, we just fix up the ticket ids, because the messages will still be correct.
understood, no more q's ;)
Unassigning me from this so I focus on other things first.
Split is in r597.
One of the options shown when splitting a ticket is "The new ticket should have every reply from this message (including this message)"
Is it just me or is that an odd way to phrase it? Is the first instance of the word "message" really referring to the ticket, or does it mean to say "from this message forward" or something like that?
Yeah, it's a bad phrasing.
The two options amount to:
* split the ticket so only this message is the new ticket
* split the ticket so this message and everything after it is the new ticket
They are absolutely analogous to the first two options provided by SMF for splitting a topic; I didn't feel a burning need to include the third option (picking which replies) since that's a nightmare enough in SMF, and doubly so for us because of recycling.
Though I am debating whether we should include PM the user functionality here like there is for topic/ticket.
Added PM user functionality, tidied up the UI a little (but likely needs more work)
In the split ticket dialog, it says "Send a PM to the ticket starter:" and indeed, a PM is sent to the person who created the originating ticket, while the new ticket will belong to the author of the split "post." Should there be the option to assign ownership of the split ticket also to the originator of the first ticket? And perhaps the ability to assign a relationship between the two tickets? I could see opening a new ticket this way for a customer by going to what will be the "Parent" or "Sibling" ticket, posting a comment, and then spawning that comment into a child or sibling ticket by splitting it off.
The assigning to a different user I know is in the road map, but this would definitely be a nice place to have it, even if it's an either/or option between originator of the ticket and originator of the split post. And offering to build a relationship between the split tickets seems like a natural.
Well, that's one of the fundamental issues, the person who wrote the first post is the ticket owner by definition, and I think that's going to have to be separated both for this and for proxy tickets anyhow.
Option of creating a parent/child relationship is a good idea, I think.
Hmm, the more I think about this, the messier it gets.
Merge implicitly requires that the two tickets are from the same user (I don't think I made that explicit thus far), to avoid this issue. Split, the way I worded the permission implies it only splits it where the new ticket would have the same starter as the original. I don't remember if I made that the case when presenting the option to the user and I definitely didn't add a check for that in the code.
Creating a relationship makes perfect sense to add as an option, so I can definitely look at doing that as part of finishing this feature.
The easiest thing to do here would be to just add a option on related tickets to merge them if and only if the topic starter are the same.
Possibly allow it if the other topic is started by a staff member..
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.
throwing a nudge here.
Can we decide how to handle this or move it to a later release if its too complicated
I have to say that I forget the status of this. I haven't played with SD for a long time. I thought it was fairly well complete, though with a couple of needed options? Is it at the point where it would be harder to strip it out than to finish it?
Without reading the above posts, I think it was far from done, IIRC. It'd probably be easier to leave it for 1.2 or even 1.3, I don't consider it an important feature personally.
Any other thoughts? Do we want this feature for 1.1, if it's not too far from done?
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.
! Disable all merge/split stuff since it has been moved to 1.2 Revision: 16
Thoughts on this.... 2.1, Future?
Split individual post or split ticket should have been done, and merge was partly done. Still debating whether this is going to be included or not but personally I think it's not too big to do.
And who would own the ticket created at split
Original ticket owner, author of the post, person making the split?
The code that I had only allowed a split on posts where the reply was by the original ticket starter, so that the new ticket would be owned by the same person.
And that does come with the option of splitting just that post or include all posts after correct?
Need to double check but I think I implemented the choice.
Yup, definitely going to put this one in.
Actually, I'm going to pull this out.
Split ticket isn't overly useful the way it's implemented, merge ticket won't be any more useful - either way where you have to keep the ticket starter set the same way, it just ends up being mostly useless. So this can go to future, because it needs more thinking in it.
I was gonna wait til it's implemented and test it out before adding to it...
Honestly I was confused as to why a split would only be possible if the ticket owner is the same as the author of the reply being split.
My original thought was wherever a split occurs the author of the split post becomes the new ticket's author, on merge the author of the first ticket (date and time) remains the ticket author.
Take sm.org for example it's very likely that a user would see a support topic and think hey I'm having a similar issue and post in the existing thread opposed to starting their own... most likely it's the new poster's reply that would be split off.
Now lets take a bugtracker situation... there's a ticket about a feature and during the discussion someone besides the ticket author adds some info that better off as its own ticket, you'd want to split that off to properly track it.
JMO
Yes, in a bug tracker, that works fine - but in a help desk, it fails at the first hurdle because the ticket starter now can't see all of their ticket, and generally, you wouldn't have it diverging like it does in a forum.
Ah, now I see the logic behind it
But even so, only merge would be affected, correct?
If you merge a ticket, then who is the ticket starter?
I see the problem you are getting at Gruffen. I don't think there is any way logically to resolve this until the point in the future when we allow group/chlid accounts. Not sure if that could even allow it so we would have to set things up to allow for multiple ticket starters/multiple access to the ticket.
This is really something that needs to be saved for the next version because all of that requires rethinking our authorization model again (not authentication!)
Really controversial change coming up...
Because of the level of change that will be required in the future for this to be successful (in light of SleePy's comment about multi-user access etc.), I'm actually going to remove what code there is for this entirely because right now it's absolutely dead weight, and even when it does re-emerge, it'll be quite different anyway.