Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API: How to retrieve the current active policies #939

Open
mrsimpson opened this issue Mar 15, 2022 · 1 comment
Open

API: How to retrieve the current active policies #939

mrsimpson opened this issue Mar 15, 2022 · 1 comment
Assignees

Comments

@mrsimpson
Copy link

Motivation

When visualizing the currently effective regulations of an agency, all policies which are not superseeded are relevant.

Problem

As per the specification, all published policies are immutable. Versioning and outdating superseeded policies is achieved by publishing a new policy, which holds the prev policies as a reference. While this is technically elegant (as the previous policy is really immutable and not even it's state is manipulated after publishing), it's cumbersome as a consumeras per the MDS policy read api, there is no option to retrieve only those policies which are not referenced as a prev policy by another one.

Ideas

It was nice if there was a transient state which could be queried for. This enum value would then internally get transformed to a query which in-/exludes the policy from prev. policies.
While this sounds simple at first, it gets a bit tricky in detail: Both the information, whether a policy is published or "active" (not superseeded) depends on the point in time which is used to look at the states.
Is there already a solution for that or does it need to be added to the implementation (and spec, yay!)?

@avatarneil
Copy link

Hi @mrsimpson, so funnily enough.. I'm pretty sure the current implementation in mds-core of the mds-policy-api actually does filter for only active policies within the queried time range. We ran into the exact same issue a couple years ago. Note, this behavior is a little out of spec; however, we haven't heard anyone complain about this additional filtering we've applied, and historical policies are still accessible by direct UUID lookup.

This could very well be something that should get promoted to spec level as a query parameter, though!

@avatarneil avatarneil self-assigned this Mar 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants