Closed (fixed)
Project:
Views (for Drupal 7)
Version:
7.x-3.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
2 Jun 2011 at 00:44 UTC
Updated:
4 Jan 2014 at 00:53 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mstrelan commentedTitle should read "field", not "filter".
Comment #2
dawehnerThe code at the top of views_ui_standard_submit() has to be executed on views_ui_config_item_form_remove as well.
Just to write down for the person who fixes this.
Comment #3
sachbearbeiter commentedsubscribe
Comment #4
merlinofchaos commentedThis is an artifact of changing override from a button to a select, it looks like. This is somewhat related to #1174070: Improve UI for "Apply (this display)" though it is not actually the same thing, but it's a similar thing that wasn't, unfortunately, well considered in the new UI.
Comment #5
dawehnerThis patch would work in theory BUT the problem is that form_state['values'] is pretty much empty in views_ui_config_item_form_remove
Any idea what the reason could be?
Comment #6
dawehnerPerhaps views does something special with #validate or #limit_validation_errors
Comment #7
sachbearbeiter commenteddoes somebody has an solution?
Comment #8
dawehnerEverytime you write a comment like this in the issue queue two kittens die.
Comment #9
delta commentedsubscribe i have the same problem
Comment #10
dawehner@delta, @sachbearbeiter
You subscribed here so you should read this via mail :) Please test the patch!
If you think it's important, as you did because you posted something here, please test the patch.
Comment #11
mstrelan commentedThe patch doesn't work, not following the exact steps of the OP anyway.
Comment #12
dawehnerJust tagging to catch them all.
Comment #13
dpolant commentedsubscribe
Comment #14
dawehnerFeel free to look at the other issues with the same tag.
Comment #15
dawehnerIn general this patch doesn't apply at the moment so there is work todo.
Comment #16
dawehnerHere is a rerole of the patch.
Comment #17
filijonka commentedHi
I tested the patch and it didn't seem to work; same problem occur.
I'll take a closer look to the code later on today or tomorrow.
the question I'm thinking is: should this really even be possible? Should an admin be able to set it to override and therefor expect it to be overriden before saved?
Comment #18
filijonka commentedI made the same changes that the patch above + changed in views_ui_standard_override_values
Comment #19
tim.plunkett#16 didn't work, but #18 works perfectly.
As long as the s/values/input in the middle hunk is okay, this is good to go. I'm not 100% sure about that change, but it seems reasonable.
Comment #20
dawehnerThe problem is: why is input required here. Well in fact you can validate the override part and everything is fine.
Awesome! Thanks earl!
Comment #21
tim.plunkettI really need to learn more about #limit_validation_errors. This also works, and makes more sense.
Comment #22
dawehnerYEAAAH
Release feels pretty close.
Comment #23
filijonka commentedplease feel free to explain this more in detail, eager to learn
Comment #24
dawehnerOkay: if you have a #limit_validation_errors on a submit button you can limit the form elements which are validated.
Only validated form elements set values to $form_state['values']
So we need the form elements from form $form['override'] so we only validate this values.
Comment #25
filijonka commentedhi
a big aha from me :) A way smarter and more correct solution than the one I gave.
thanks for your time
Comment #26
dawehnerNo thank you for providing an initial fix :) This leads to the idea how to fix it perfect.