View Issue Details

IDProjectCategoryView StatusLast Update
0011763mantisbtotherpublic2016-10-15 20:37
Reporterdavid_s_nl Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version1.2.0 
Summary0011763: Ability to escape bug linking
Description

Hi,

When typing the hash character followed by a number in a text field Mantis automatically creates a link to the corresponding issue, for example: 0011763

However, every now and then i encounter a situation where i want to insert for example an error log containing hashes, without having Mantis convert it to a bug link, because this complicates reading the actual text.

It would be convenient if there would be a way to prevent this by using an escape character.

Additional Information

I have tested this by changing line 371 in "string_process_bug_link" in string_api.php.

By doing this, if i type a backslash before the hash, it will not get converted to a link, and the backslash will not be displayed.
For example: #issuenumberhere

BEWARE, i have never written a single line of code in PHP and regular expressions give me headaches... so i recommend you do NOT use this :)

#do not convert to bug link if hash is preceded by backslash
$p_string = preg_replace_callback( '/(^|[^\w&\\])' . preg_quote( $t_tag, '/' ) . '(\d+)\b/', $string_process_bug_link_callback[$p_include_anchor][$p_detail_info][$p_fqdn], $p_string );
#remove backslash
$p_string = preg_replace('/(\\)(' . preg_quote( $t_tag, '/' ) . '\d+)\b/', '${2}', $p_string);
return $p_string ;

TagsNo tags attached.
Attached Files

Relationships

related to 0020503 new Consider not expanding issues and notes internal links in some places 

Activities

dana

dana

2016-10-14 19:52

reporter   ~0054226

I would also like to see some improvement in this area.

Not only is it confusing and irritating when it insists on auto-linking something you don't want, but in some cases it can actually break Mantis. For example, someone had sarcastically written the phrase 'attempt #938402394820928309482034' in a ticket, and now any time we try to update that ticket we get this error:

Database query failed. Error received from database was #-1: ERROR: value "9223372036854775807" is out of range for type integer for the query: SELECT * FROM mantis_bug_table WHERE id=$1.

Evidently Mantis tries to interpret any number following a hash, no matter how comically large, as a ticket number, and then tries to look it up in the database.

I'd actually worked around the problem for the most part by replacing Mantis's default formatting plug-in with one that has a sort of pre-processor for escaping.... Probably i have Mantis configured not to use my pre-processor for e-mail notifications, so that's why i still get that error.

The attached file contains the method i use in my formatting plug-in for handling back-slash-escaping of # and ~, as well as auto-escaping of #, ~, and @ inside code and pre elements. Not sure how performant it is — it works pretty well for our small installation, though it needs updated to use Mantis's facilities for getting the user-configured sigils instead of having them hard-coded in. If it would be in any way useful to anybody, you can consider this code to be released under the MIT and/or GPL 2+ licences.

escapeSpecialChars.php (1,420 bytes)   
<?php

/**
 * Escapes special characters that Mantis might otherwise mangle.
 *
 * @param string $text The text to process.
 *
 * @return string The text after any escaping.
 */
protected function escapeSpecialChars($text) {
	// Escape all #/@/~ inside <pre> and <code>
	$text = preg_replace_callback(
		'%(<(pre|code)(?:\s[^>]*)?>)(.+?)(</\2\s*>)%ism',
		function ($matches) {
			$matches[3] = mb_encode_numericentity(
				$matches[3],
				[
					// '#'
					0x23, 0x23, 0, 0xff,
					// '@'
					0x40, 0x40, 0, 0xff,
					// '~'
					0x7e, 0x7e, 0, 0xff,
				],
				'UTF-8'
			);
			return implode('', [
				$matches[1],
				$matches[3],
				$matches[4],
			]);
		},
		$text
	);

	// Escape all #/~ preceded by back-slashes
	$text = preg_replace_callback(
		'%(\\\\+)([#~])(\d)%',
		function ($matches) {
			$backslashes = $matches[1];
			$char        = $matches[2];
			$number      = $matches[3];

			// Even number of back-slashes
			if ( ($len = strlen($backslashes)) && $len % 2 === 0 ) {
				$backslashes = substr($backslashes, floor($len / 2));
			// Odd number of back-slashes
			} else {
				$backslashes = substr($backslashes, floor($len / 2) + 1);
				$char        = mb_encode_numericentity($char, [
					// '#'
					0x23, 0x23, 0, 0xff,
					// '~'
					0x7e, 0x7e, 0, 0xff,
				], 'UTF-8');
			}

			return implode('', [
				$backslashes,
				$char,
				$number,
			]);
		},
		$text
	);

	return $text;
}

escapeSpecialChars.php (1,420 bytes)   
Chris_Z

Chris_Z

2016-10-15 05:44

reporter   ~0054227

The default text formatting plugin seems to respect hash character when it is immediately preceded by any other character than white space. Attaching a screenshot showing both cases. Mantis 2.0 Beta 3.

Snapshot-2016-10-15-112909.png (79,353 bytes)   
Snapshot-2016-10-15-112909.png (79,353 bytes)   
dana

dana

2016-10-15 05:49

reporter   ~0054228

That's about right, the pattern it uses to catch bug links is:

'/(^|[^\w&])' . preg_quote( $t_tag, '/' ) . '(\d+)\b/'

cproensa

cproensa

2016-10-15 17:40

developer   ~0054235

@dana

Not only is it confusing and irritating when it insists on auto-linking something you don't want, but in some cases it can actually break Mantis. For example, someone had sarcastically written the phrase 'attempt #938402394820928309482034' in a ticket, and now any time we try to update that ticket we get this error:

I can't reproduce that error. If you can, please report it with details, so it can be fixed

cproensa

cproensa

2016-10-15 17:44

developer   ~0054236

Ideally, the bug/note replacement should not be performed within preformatted parts of text. For example: "pre" tags, or equivalent notation.

But that is not feasible with current system, a proper parser is required to do that correctly.

dana

dana

2016-10-15 20:37

reporter   ~0054237

@cproensa done, see 0021802