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

Comments

Projects
None yet
4 participants
@yohanboniface
Copy link

commented May 18, 2016

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented May 19, 2016

@yohanboniface

This comment has been minimized.

Copy link
Author

commented Jun 1, 2016

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

commented May 31, 2018

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

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

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

This comment has been minimized.

Copy link
Member

commented Jun 15, 2018

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

@yohanboniface

This comment has been minimized.

Copy link
Author

commented Jun 15, 2018

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
You can’t perform that action at this time.