#1423 Optional Exception on Mass-assignment of Protected Attributes - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#1423 ✓duplicate

Optional Exception on Mass-assignment of Protected Attributes

Reported by Nate | November 20th, 2008 @ 08:16 PM | in 2.x

Originally squashed here: http://dev.rubyonrails.org/ticke...

What do you guys think of restoring this functionality, but defaulting to the current behavior? That is, have a configuration option that lets you turn on whiny mass-assignment of protected attributes, but by default it just does logger.debug with a warning. I know that during development I get bit by missing the debug messages way too often when adding fields and changing forms.

If there's interest I can patch it.

Comments and changes to this ticket

You flagged this item as spam.
Nate November 20th, 2008 @ 08:19 PM
Oh, and by interest I mean more interest than just me and the company I work for.
You flagged this item as spam.
Tammer Saleh November 20th, 2008 @ 08:44 PM
+1

The ARes argument is the first one I've heard for not raising on an attempt to mass-update a protected attribute, and it seems like somewhat of an edge case. Given the developer headache that can arise from silently ignoring protected attrs (we have had tons), I'd be in favor of defaulting to raising and having a silent option.
You flagged this item as spam.
Oliver Legg December 3rd, 2008 @ 11:33 AM
+1

I think this should be configurable, so that the behavior can be different depending on environment.

This always bites me. I turn everything to protected by default and when using the console I try and use the short hand and I spend 5 minutes figuring our what I did wrong. Failing loudly would be preferable.
You flagged this item as spam.
Nate December 10th, 2008 @ 09:40 PM
any input from core on this one?
You flagged this item as spam.
Brandon December 10th, 2008 @ 09:41 PM
+1

I'd love for raising to be the default, but getting the option would be a great start at least.
You flagged this item as spam.
Norbert Crombach December 10th, 2008 @ 10:00 PM
+1

The default is good, but I'd use this instead.
Jeremy Kemper December 10th, 2008 @ 10:45 PM
This was on by default for a while, but caused widespread low-level pain. I'm not sure that turning it on and off application-wide will really help with that.
Dan Pickett December 10th, 2008 @ 10:57 PM
+1 - I often overlook the debugging messages inadvertently.
Pratik March 12th, 2009 @ 04:32 PM
- Assigned user set to “Jeremy Kemper”
Frederick Cheung May 10th, 2009 @ 06:05 PM
- State changed from “new” to “duplicate”
#2388 has a patch implementing this