View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0024681 | mantisbt | feature | public | 2018-08-20 05:38 | 2018-08-22 08:20 |
Reporter | Bozz | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 2.16.0 | ||||
Summary | 0024681: Add the possibility to configure multiple bug link tags | ||||
Description | Hi, We have been using Mantis for a while now, integrated at the beginning with SVN, and we migrated a while ago some of our projects to GitLab. The issue we have now is the cross referencing of issues. I tried to configure the Mantis configuration $g_bug_link_tag like so $g_bug_link_tag = '#|MANTIS-'; but it seems like the parameters does not accept these characters '|' and '-' even though it seems to be parsed as a regular expression:
feature request: Will it be possible to configure a list of possible bug link tags please ? Thank you. | ||||
Tags | No tags attached. | ||||
Hi, here is a proposal for a fix:
|
|
This is because we use preg_quote() to ensure that whatever character(s) are used in $g_bug_link_tag are taken literally and not as part of the regex. To achieve the desired feature, I think it would be better to define the config for multiple tags as an array, instead of splitting a string by EDIT: probably a callback function is needed for array_map, so preg_quote can be called with That being said, I'm a bit concerned about performance. PCRE and callback functions are slow, so pages with many bug links could have degraded response times (but I did not actually benchmark this). Finally, for consistency I think the same change should be applied to bugnote tags. Let me know your thoughts. |
|
Damien your solution seems reasonably good to me, though I don’t have anything to say about perf issues (But the current implementation already uses pcre and callbacks as it seems). I thought about proposing a change of that prop into an array as well, but that would mean a breaking change! Or introducing a new config prop but it would then mean deal with @deprecated config otherwise. In any case, I don’t really mind the final solution to choose :-) |
|
About performance: on second thoughts, the preprocessing overhead necessary to handle multiple tags based on an array (whether it's based on a foreach loop or a more complex regex) will most likely be negligible compared to the cost of having preg_replace_callback() execute the closure for each pattern match. I'll try to run some benchmark as time allows, but
I don't think deprecating the config is necessary - backwards-compatibility can easily be achieved with |
|