Home → Problems →

Broken link to private discussion

• Edit

josh

Jan 12, 2010 @ 12:49 AM

I have a private category, and setup an email address that forwards into that category. Then I sent a test email to that address, and responded to the test issue from within Tender. In that response email, a line like:

View this PRIVATE Discussion online:

was sent to my test customer. However the link just asks the person to login, but they have no login since they never created one - they just sent an email.

1. 1 Posted by josh on Jan 12, 2010 @ 12:53 AM

   

   Oh another bug, in my original post, I included:

   left-angle-bracket URL right-angle-bracket

   as part of the view this PRIVATE discussion line, but it seems that got stripped out of my post. I don't think that should get stripped out. We have a somewhat technical service and frequently need to communicate customers with examples, and even share HTML/JavaScript code snippets. If angle brackets get stripped out these emails won't make any sense and we won't be able to share these basic code snippets to help customers.

   • Edit

2. 2 Posted by josh on Jan 12, 2010 @ 02:05 PM

   

   Sorry you can ignore the initial issue - I previously had registered the email address I performed the test on, and I didn't realize Tender would be smart enough to realize that an account already existed for this ticket even though I sent the issue from an email rather than a logged in account - pretty cool :)

   The other issue really is a show-stopper though, we need to exchange HTML snippets with customers.

   • Edit

3. 3 Posted by Will on Jan 12, 2010 @ 08:38 PM

   

   Hey Josh,

   On your brackets issue, can you provide the title of an email you send it as an example? or was this posted from the web?

   • Edit

4. 4 Posted by josh on Jan 13, 2010 @ 01:31 AM

   

   It was posted from the web. Doing a test now: inside b tag < inside brackets with space >

   • Edit

5. 5 Posted by josh on Jan 13, 2010 @ 01:34 AM

   

   Another test:

   • Edit

6. 6 Posted by josh on Jan 13, 2010 @ 01:37 AM

   

   Ok it looks like a HTML b tag got rendered as a bold, and a HTML script tag just got removed. I guess that may be a feature for you guys, but is there a way to disable it so we could provide support on some web issues?

   There is also some weirdness about putting text inside single brackets from the web, brackets seem to get removed or combined. But probably it's just a part of whatever is parsing the HTML tags. The real issue is we don't want any parsing of HTML tags, just to have them displayed as text.

   • Edit

7. 7 Posted by rick on Jan 13, 2010 @ 06:14 PM

   

   You'll want to go into code mode to put in raw html. You can either indent by four spaces or surround the area with @@@

   non-code
   
       <script>alert('foo')</script>
   
   @@@ html
   <script>alert('foo')</script>
   @@@
   

   That should look like this:

   <script>alert('foo')</script>
   

   <script>alert('foo')</script>
   

   • Edit

8. 8 Posted by josh on Jan 14, 2010 @ 11:35 AM

   

   That sounds like it will do it for our side, though I wish it could be more obvious for our users. We'll just roll with it and see how big of a problem it becomes. We'd ideally have an option to make code mode the default but realize you don't want a million and one configuration options :)

   • Edit

9. Support Staff 9 Posted by Courtenay on Jan 14, 2010 @ 11:52 AM

   

   Yeah, I can see a use case for sites that deal with a lot of html. We
   could prrrrrobably try and attempt to magically parse out blocks of
   code out - or - make the whole thing a `code` tag if it has `script`
   or other such html in it..?

   I'll add it to the list of things to consider in the next round of
   features. This will be more of an issue once we open up the open
   source plans a little more.

   • Edit

10. 10 Posted by josh on Jan 14, 2010 @ 01:28 PM

    

    My 2c is since you are already using Markdown syntax options, there is no need to parse HTML, and the easiest solution would be to just let HTML tags pass unhindered. Magically detecting this code and making it a code block would be a bonus, but even w/o this it would be fine. The main drawback with this is that some people will try to embed a tags or something to make links, but they can quickly learn, and since you have the edit functionality they can clean up their error.

    Another random comment is that the parsed with Markdown link is rather technical and weird for a support site to link to a 2004 blog post. It's ok for my users since they are semi-technical but may be more of a problem if your user base widens.

    • Edit

11. Support Staff 11 Posted by Courtenay on Jan 14, 2010 @ 01:31 PM

    

    The issue as you say is if someone tries to (innocently) use html in
    their comment (we also parse incoming html emails, making things
    harder again) -- hence, looking at the contents and seeing if it looks
    like some sort of html paste in there. I wouldn't be parsing it, just
    inspecting to determine.

    Sure is a tricky one. Thanks for the feedback, appreciate it.

    • Edit

12. 12 Posted by rick on Jan 14, 2010 @ 01:54 PM

    

    It's no accident that Markdown lets you insert HTML into the text.
    However, I think if you're inserting HTML into a support issue, you
    are already fairly technical. As our user base widens, the customers
    will be talking about less technical stuff.

    The only solution in my mind is making Markdown opt-in.

    • Edit

13. Nicole closed this discussion on Feb 05, 2010 @ 09:28 PM.