Repository navigation
Disregard title suffixes when finding linked fasttrack questions - #842
Conversation
If the concept name is "Title", this query should also match questions titled "Title 1i", "Title 1ii", "Title 2i",... This must be a regex query rather than a prefix query to avoid clashes between topics with similar names (e.g. "Circles" vs "Circles and Geometry").
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #842 +/- ##
==========================================
- Coverage 41.63% 41.61% -0.03%
==========================================
Files 552 553 +1
Lines 23759 23773 +14
Branches 2884 2885 +1
==========================================
Hits 9892 9892
- Misses 12969 12983 +14
Partials 898 898 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Should work OK on the content we now have (I haven't checked though), and the regexp is specific enough I'm not too worried about it accidentally matching content.
However, the fasttrack graph is just as broken (at least for me locally) as it was without these changes when I visit a fasttrack page on the new content. I think this is because once the title goes "2x2 Operations" -> "2x2 Operations 1ii", titleRegex becomes 2x2 Operations 1ii([ ][0-9]+i{1,2})?, which matches nothing.
Good spot. This was being handled in the frontend changes, but since we'll need to run these API changes alongside the current frontend for a while, the title sanitisation ought to be moved here instead. |
barna-isaac
left a comment
There was a problem hiding this comment.
Re-tested this using the proposed final state (updated APP and API), titles in content include fasttrack suffixes. Looks good!
If the concept name is "Title", this query should also match questions titled "Title 1i", "Title 1ii", "Title 2i",...
Until next week's release, the content's titles (both in the
conceptTitlesent by the frontend and in the ES index) will not contain the suffixes. These changes are backwards-compatible with this; the regex match encapsulates an exact match as was used before.