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

@yohanboniface yohanboniface 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
Copy link
Member

@nicolaiarocci 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 funkyfuture commented May 19, 2016

@yohanboniface
Copy link
Author

@yohanboniface yohanboniface 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
Copy link

@drcraig 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

@funkyfuture funkyfuture 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
Copy link
Member

@funkyfuture funkyfuture 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
Copy link
Member

@funkyfuture funkyfuture 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
Copy link
Author

@yohanboniface yohanboniface 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants