Comments (4)
After some additional thought I believe the server should separate out different kinds of rating operations, and separate these from basic CRUD operations (i.e. create/update/delete a system, etc etc). We'd thought about having a system POST return an approval, but I think this makes the response kind of confusing , since every other CRUD endpoint should return the object in question.
Ultimately came up with this:
For consistency all rating actions will happen under /endpoint/rate.
/system/rate/:id
Create and return the approval for an existing system
/system/rate/dry-run
Create and return the approval for the posted system as a dry-run. In this case the posted system is not stored
(proposed)
/system/rate/:id/current
Last seen rating for this system (i.e. the current known state)
/registry/rate/:id
Create and return the approval record for an existing registry
/registry/rate/dry-run
Create and return the approval for the posted registry as a dry-run. In this case the posted registry is not stored
(proposed)
/registry/rate/:id/current
Last seen rating for this registry (i.e. the current known state)
from fides.
Notes from standup with Steven:
- The main value of the feature here is for someone to check the current state of their manifest files against the server and know if they're valid or not
- This doesn't need to be tracked by the server, git + ci checks will show the manifest files going in and out of a valid state. This is a completely ephemeral and non-destructive command
- Should look something like
fidesctl evaluate --dry-run <manifests_dir>
@stevenbenjamin this feels pretty closely tied to the workflow things we want to solve, and we're in agreement there should only be one command that can be used with or without a dry-run flag. feel free to put your workflow thoughts here or in another issue
from fides.
@stevenbenjamin A few thoughts here
- I'd prefer to use
fidesKey
instead of the id for lookups, otherwise it always adds another step of the CLI needing to look up the object first just to get its id - for these endpoints, are you envisioning all of the manifests being sent for a dryrun or just the system? if you do a dryrun and only submit the new system, what about the changes made to other parts of the manifests? i might want to make a policy change in an MR that would affect how a system behaves, or add a new dataUse, etc. and these would all need to be sent together to evaluate an object in its entirety
- the
rate
term is being deprecated in favor orevaluate
,rate
evokes a numerical scoring or a spectrum, whereas we just have a pass/fail
from fides.
-
i understand the convenience of this, but it does get into consistency issues. How do we make this consistent with the rest of the API? shouldn't there be some way of assigning/storing the api values with the manifest?
-
There are no other manifests other than system manifests.
Policy changes need to be submitted separately, since a policy is organization wide, it needs to be re-applied to everything when you update it. this is not workable if you're constantly re-submitting. Ditto for resubmitting a piece of the taxonomy.
The model of "systems, rules, taxonomy types, etc" all stored in one place and continually reapplied is broken and will not work with the server as written. the server is built on the model of an in-place set of rules/taxonomy values that systems/registries are evaluated against. Your model will break completely if commits are coming from multiple places. -
Naming change is not a problem.
from fides.
Related Issues (20)
- Replace `fides-js` direct calls to gvl.json with datamap data instead HOT 2
- `systems-plus.cy.ts` has a flaky test HOT 1
- Update dictionary suggestion inputs to be individually revertable
- Filtering and bulk editing for consent table
- Consent table that supports TCF/non-TCF
- Wildcard CORS Origin Cannot be Passed in via Environment Variable
- Build a better form input for time durations HOT 1
- Fix bug with re-selecting vendor in "add vendor" modal on configure consent page
- Update color for focus state on form inputs
- Refactor common code from consent-banner-tcf.cy.ts
- Add support for named config overrides in Fides.js
- Clean up CSS for fides_embed banner
- Consent serving may not send proper `served_notice_history_id` on slow connections HOT 1
- Disable "vendor" field when locking forms for GVL
- Form is not autofilled on selecting vendor for non-GVL systems
- "Generate data uses" button shown when no data uses can be generated
- "Tags" field in system form not being populated from Compass
- Can create a system with a duplicate name
- Button to populate data uses from Compass still present on data use display table
- PROD-1297: Typeahead vendor selector improvements
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fides.