Hide modules from old drafts in impact analysis

[richardzilincikPantheon]

This issue might need to be moved to YangCatalog/module-compilation depending on how we address it.

ospf-topology is from draft-ietf-i2rs-yang-l3-topology-00.txt and was removed in subsequent versions of the draft, which was later finalized into an RFC. It should not be visible when only the ratified and adopted check boxes are selected.

Within YC, adopted is defines as:

"Maturity of a module that is actively being developed by a organization towards ratification."

Possible ways of addressing this would be:

1. checking the "expired" property of a module unless the "not-applicable" check box is also selected on second thought, this sounds like it would be very confusing
2. changing the maturity of expired modules to "not-applicable"

Option 2 would be more consistent and also affect the maturity value displayed in the module details and other places. However I don't know whether it was an intentional choice to leave expired modules as adopted. @SlavomirMazurPantheon do you know whether modules from outdated drafts should stay as adopted or if we can change it?

[richardzilincikPantheon]

Some additional possible ways to resolve this could be

3. The maturity-level field is optional, it could be cleared for modules belonging to expired drafts and as a result they wouldn't be visible if any of the maturity level check-boxes were selected. In this cases there would be no visible maturity level for these modules on their module details page or other places either.
4. Add a new checkbox along the lines of "show only modules from the same document". Only modules defined in the same document as the module that was searched for would be visible.

[richardzilincikPantheon]

This will be addressed by the impact analysis endpoint adding the expired field for each module to the response. The frontend can then use this information to filter the modules as expected.

[richardzilincikPantheon]

resolved by #717