Added backend endpoint for visual distinction between ratified …

[dmytro-kyrychenko]

…and non-ratified revisions

[codecov[bot]]

Codecov Report

Merging #718 (def5491) into develop (f34d191) will decrease coverage by 0.02%. The diff coverage is 0.00%.

:exclamation: Current head def5491 differs from pull request most recent head 9173bb7. Consider uploading reports for the commit 9173bb7 to get more accurate results

@@             Coverage Diff             @@
##           develop     #718      +/-   ##
===========================================
- Coverage    78.02%   78.00%   -0.02%     
===========================================
  Files          112      112              
  Lines        12710    12713       +3     
===========================================
  Hits          9917     9917              
- Misses        2793     2796       +3     

Impacted Files	Coverage Δ
api/views/yangSearch/yangSearch.py	14.65% <0.00%> (-0.09%)	:arrow_down:

[SlavomirMazurPantheon]

@dmytro-kyrychenko try to investigate whether it would be possible to extend functionality in existing API endpoint: https://yangcatalog.org/api/yang-search/v2/module-details/ietf-routing One of its properties is revisions which is list of strings (string = revision in this case). Maybe it should return list of revisions, with flag whether it is or is not a ratified module

{
    "current-module": "ietf-routing@2018-03-13.yang",
    "metadata": {},
    "revisions": [
        {"2018-03-13", true}
        {"2018-01-25", false}
    ]
}

I think. that list of revisions if currently fetched from ElasticSearch and since previous release we are also indexing info about maturity-level into Elastic so it might worth checking.

[richardzilincikPantheon]

and since previous release we are also indexing info about maturity-level into Elastic

We do, but not in the autocomplete index. I think it wouldn't be a problem to search the yindex instead, in fact that would probably work everywhere we currently use the autocomplete index. Getting the info directly from ES would also mean we don't have to make a request to redis for every revision of the module.