Loading Profile...
File Attachment support on tickets for xlsx, pdf, docx
Attachment support for PDF, xls, xlsx, doc, docx, etc. would be very helpful. Currently we are only allowed to attach image files.
2
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company implemented this idea.
The best points from the company
-
I'm going to wait until this weekend to release this, but it's officially ready for release. Thanks for waiting, and more importantly thanks for understanding while we deliberated on this.
I’m excited
The company and 1 other person think
this is one of the best points
-
This is something that we're thinking about, but we're being very cautious about it. Within Sifter, our goal is to keep each issue very atomic. The file uploading is designed specifically to support tracking of cosmetic or visual issues, and in that respect, the files are just a substitute for an issue description.
We're hesitant to support additional document types because Sifter isn't designed to be used as a file repository. So, in our experience, if there's a file other than an image involved, Sifter probably isn't the best place to keep track of it.
That said, we're being open-minded, and I'd love to hear more about how the files fit into your workflow so that I can understand how Sifter might best support them.
The company thinks
this is one of the best points
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?This is something that we're thinking about, but we're being very cautious about it. Within Sifter, our goal is to keep each issue very atomic. The file uploading is designed specifically to support tracking of cosmetic or visual issues, and in that respect, the files are just a substitute for an issue description.
We're hesitant to support additional document types because Sifter isn't designed to be used as a file repository. So, in our experience, if there's a file other than an image involved, Sifter probably isn't the best place to keep track of it.
That said, we're being open-minded, and I'd love to hear more about how the files fit into your workflow so that I can understand how Sifter might best support them.
The company thinks
this is one of the best points
-
Inappropriate?Very strange decision. Clients often want to attach emails from customers etc. Why not let them?
This could be a deal breaker..
I’m frustrated
1 Comment Add a comment
This is one of the best points
-
So far, upon digging deeper, everyone I've talked to doesn't want to *attach files to issues* so much as they just want to *upload files*. Unfortunately, Sifter isn't designed to be used as a file repository, and that would, in our opinion, dilute it's purpose and muddy the waters.
For example, with emails, why would you want to attach an email when you could just copy and paste the body of that email? By copying and pasting, the text is indexable and searchable within Sifter when it wouldn't be in an attachment. More importantly, if it's in the body of the issue you can read it without having to open an attachment.
I'm not saying that there aren't valid scenarios where uploading non-image files makes sense, but so far, nobody has really provided one. (The best request we've had is uploading patches, but until we start getting into source control integration or supporting public open-source projects, we're putting that on the back burner.)
I'd love to hear more about how you use the files in your workflow so we can give it more serious consideration. We're not deeply opposed to this, we just want to be really careful about adding things without understanding the underlying needs that justify them. Unfortunately, so far, that underlying need hasn't been enough justification. -
Inappropriate?To make clients cut and paste from existing documents (when they are collating support issues from customers that have been passed onto them from a colleague in a Word document, for example) is to enforce a new way of working upon them, that they will see as a waste of their time. Whilst I may understand that cutting and pasting into the Sifter site will make things easier our clients will not adopt the system if they cannot work the way they wish to.
1 Comment Add a comment
This is one of the best points
-
I wasn't referring to cutting and pasting form all documents. While I agree that people will not want to adapt their way of working, the solution for handling email is to enable them the ability to simply forward an email into Sifter rather than saving the email and then uploading the file. That's something we're working on, but it's been put on hold for a little while so we can make some other improvements.
Can you provide more concrete examples or situations where you need support for specific types of files to support creating or resolving issues? -
Inappropriate?If you are working on design changes, isn't it feasible that someone would want to upload a PSD file with those changes? In this case, a jpg/png may not be sufficient since you may need the source file itself. I've run into similar situations with css/javascript files. An issue may result in updated code. It would be nice to be able to attach those to an issue as part of the resolution of it.
By not allowing these files to be uploaded are you sacrificing Sifter's ability to keep track of an issue's resolution?
Something to think about, as well, when Sifter gets the ability to accept email, those emails may have attachments. If you aren't saving those attachments, then I would assume they'd just get lost. The first time I ask a client to send me an attachment separately from their support issue post, that's the last time they send an issue directly into Sifter.
Similar to Jayashri's comments, I have a client who still takes screenshots and sends them to me inside a Word document, no matter how many times I've told him he can just send the picture by itself. -
Inappropriate?PSD's and PDF's are definitely something we want to support. I've been giving more serious consideration to allowing other file formats as well, though.
With regards to email, my plan is to have a fairly robust system for processing email, and if someone sends something that doesn't work or is too large, we would send an email letting them know there were problems. We definitely don't want to just swallow things and have them disappear.
I’m increasingly optimistic
-
Inappropriate?What about an issue such as "the list of countries and languages on the server is out of date - here's an excel file with the revised list"?
I’m bothered
1 person thinks
this is one of the best points
2 Comments Add a comment
This is one of the best points
-
I've started to come around on this, and it's likely we'll implement it in the near future. I've been extremely cautious about this as i want to be with every enhancement. It's a lot easier to blindly say yes to requests than it is to give them careful consideration.
-
Thanks! I now upgrade myself to a smiley face. :-)
-
Inappropriate?I'm going to wait until this weekend to release this, but it's officially ready for release. Thanks for waiting, and more importantly thanks for understanding while we deliberated on this.
I’m excited
The company and 1 other person think
this is one of the best points
EMPLOYEE
