-
Notifications
You must be signed in to change notification settings - Fork 73
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
Fixes #13609: Change request must not be saved when no validation is needed #2043
Conversation
* These method allow to get change request impacting a rule/directive/etc. | ||
* Used to display information on them on corresponding update screens. | ||
*/ | ||
def getByDirective(id : DirectiveId, onlyPending:Boolean) : Box[Vector[ChangeRequest]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question here, why a Vector and not an IndexedSeq ? (or even a Seq/List? )
But don't change it, it's just for my knowledge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just moved (or copy/pasted) interfaces that where provided elsewhere.
Not sure for the rationnal, but the idea should have been along the line: be precise about what you give to let consumer adpat their behaviors.
// Configuration doesn't give API rights. | ||
// But as nothing manage parameter API, I think it's the correct place | ||
// to add it. | ||
case Configuration.Read => ParameterApi.ListParameters.x :: ParameterApi.ParameterDetails.x :: Nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I though Configuration was giving access to all configs (Rules/Directives/Parameters/Techniques), am i wrong ?
So it should provide access to all other element not only parameter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact it's already like that in 4.3
OK, merging this PR |
https://www.rudder-project.org/redmine/issues/13609
Some explanation: we had a problem because we used to have two repo, one false (in memory) and the real one, for change requests. When we switched the "enable change requests" status, it used to switch the repo.
That does not work in a world where the status also depends of the actual modification.
But that was not the whole problem: we used to always save a change request, even when the validation workflow was not used, so that the only step of the "no workflow" workflow was deleting the saved change in the in memory repos...
So, that PR change the flow of event so that:
In the end, that allows to completly split appart the "two step validation workflow" from Rudder, including all the repository part. I didn't touched the table creation part, because it has no consequences regarding API version or user or dev experience.
That's a big, very very welcome change. It simplifies a lot what a workflow is and what is needed to make one.
Hereby, change Validation is really independant from Rudder.