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

Interest for a purge_readonly flag? #240

Closed
yohanboniface opened this issue May 18, 2016 · 8 comments
Closed

Interest for a purge_readonly flag? #240

yohanboniface opened this issue May 18, 2016 · 8 comments
Milestone

Comments

@yohanboniface
Copy link

My use case is that I have some fields that I want to expose, but are not writable in POST/PUT/PATCH.
Instead of raising when someone pass one of them, I'd prefer to remove it from the document.
I can do that on my side, but if there is interest I can instead provide a pull request.

@nicolaiarocci
Copy link
Member

nicolaiarocci commented May 19, 2016

How would you implement that? A new purge rule maybe? Or just a purge_readonly flag as the title suggests.

@funkyfuture
Copy link
Member

funkyfuture commented May 19, 2016 via email

@yohanboniface
Copy link
Author

can you solve your need with a custom validator atm?

Yep, I've a custom one anyway.
My question was more about the interest of pushing that upstream.

And my idea was to implement a global flag purge_readonly, just like we have a purge_unknown.

I'll keep an eye on the thread to see if a preferred implementation raises up.

@drcraig
Copy link

drcraig commented Mar 21, 2017

I have the exact same usecase as @yohanboniface, and actually initially thought that's what readonly was for, but thought I was doing something wrong.

@funkyfuture
Copy link
Member

for the sake of simplicity and from what i can conceptualize as use-case, i propose to make that an instance configuration like purge_unknown and not a rule. and that this gets assigned to the 1.3 milestone. is that allright for everyone?

@nicolaiarocci nicolaiarocci added this to the 1.3 milestone Jun 1, 2018
@funkyfuture
Copy link
Member

there's one thing not to forget: the order in which the various normalization rules are applied matters. with the growing amount of possible alterations there's no way around the capability to configure that order per validator instance (and for some that might not be granular enough).

@funkyfuture
Copy link
Member

@yohanboniface, in your initial post you mention a pr. do you have some code that can be integrated into Cerberus?

@yohanboniface
Copy link
Author

Nope, sorry :(

funkyfuture added a commit to funkyfuture/cerberus that referenced this issue Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants