Devel

[majioa]

• Forced column_name variable to be passed into partials.
• boolean false value for custom display type isn't now treated as a blank.
• add a new record for has_one/has_many associations
• delete a record when csrf-token is used

[antpaw]

Hi thanks, i think you can't remove the compat layer of mootools because the form-datepicker plugin will not work

[majioa]

@antpaw that was compiled with a compat layer, just renamed.

[antpaw]

in this old file if i search for "compat" i get 69 results
in this new file i get 11
i'm sure something went wrong

[antpaw]

maybe it's not possible to have compat upto v1.2 anymore

[antpaw]

very strange, can you check if datepicker still works?

[majioa]

@antpaw updated

[antpaw]

thank you.
It would be much easier for me to merge if every change would go into different branch and it's own pull request. Stuff you are doing is not a hotfix, it's new features and hotfixes for this new features. New features need some descriptions, context and discussions.
Can you branch out of upstream/master and cherrypick the commits you want into each pull-request-branch? You can still have a master branch in your fork where all this is merged into one branch.

I don't understand why you want this csrf protection? This is protected admin area that can't be reached by a xss attack anyway.
I don't understand what this readonly feature does? If you have the attribute disabled set on the form elements, they will not send their values to the controller in the first place.

[majioa]

@antpaw This is protected admin area that can't be reached by a xss attack anyway.
How it is protected, by what?

[majioa]

If you have the attribute disabled set on the form elements, they will not send their values to the controller in the first place.

@antpaw yes, but, this does not protect it from changing by modified html. I'll play with disabled one

[antpaw]

I mean the login barrier, (you build an extra feature for it lately, something related to "device" gem) if someone can login, why would they try to do an xss attack after that. They can just clear the hole database or flood it within seconds.

If you want to protect attributes, do it in the model (this would be just one out of many other options https://github.com/rails/protected_attributes) Bhf is designed to have almost no business logic inside the controller because the bhf::controller can not be easily extended like a model or the view.

[majioa]

@antpaw the delete feature just require that authentication by validating the scrf-token. So in order to remove a record, rails just makes sure that you are admin...
by-the-way protected attributes is obsolete techinique....

[majioa]

Here I'll put fixups... dont close the branch

[antpaw]

ok

[antpaw]

i don't see how this branch, can ever be merged, unless you do some heavy git history modification and use git push --force, it should be much simpler for you (and me) to just branch out from upstream/master and do the hotfixes

[majioa]

Yes, I'll use git force.