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

dev/core#628 - Make Quicksearch options sortable #14441

Merged
merged 2 commits into from
Jun 6, 2019

Conversation

colemanw
Copy link
Member

@colemanw colemanw commented Jun 5, 2019

Overview

This is a reviewers cut of #13565, implementing the feature of allowing quicksearch options to be rearranged, but doing so in a way that is reusable for potentially other settings without any special handling.

See https://lab.civicrm.org/dev/core/issues/628

Before

image

After

image

@civibot
Copy link

civibot bot commented Jun 5, 2019

(Standard links)

@civibot civibot bot added the master label Jun 5, 2019
$element = $this->getElement('contact_autocomplete_options');
$element->_elements[0]->_flagFrozen = TRUE;
$element->_elements[0]->setAttribute('disabled', 'disabled');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally we would also specific required_options in metadata & handle this there (I'm OK with this being out of scope for this but possibly this whole form could be removed - like #14425 if we did move that to metadata

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that the current class structure is such a bad one. Makes sense to me to have all settings form inherit from a parent which does all the heavy lifting but small tweaks and overrides can be done in those classes.

These specific tweaks strike me as too weird to be generalizeable and I'm not entirely sure that "no form classes for settings pages" ought to be our goal, especially if it means "abstracting" every quirky setting behavior into a one-off metadata property.

* @param $value
* @return bool
*/
public static function enableOptionOne(&$value) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we need someone off the form layer for this - should apply to when it's set by api too

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, this is a callback set in the settings metadata. So prior to this PR it would only get handled correctly in the form layer. Now it will work everywhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@colemanw right - but I think the location of the function is wrong - I'm not sure where it should go - maybe a new class for setting callbacks, maybe setting bao, maybe select values - but not on the form

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I agree but could we take care of that in a diff PR. There are already other metadata-declared callbacks in this form class so they will all need to be relocated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess - but you are adding a callback here - still I'm OK for you to leave out of scope

@eileenmcnaughton
Copy link
Contributor

Well I tested & it works & is an improvement - merging but ideally we can move that fn again!

@eileenmcnaughton eileenmcnaughton merged commit 9aae955 into civicrm:master Jun 6, 2019
@eileenmcnaughton eileenmcnaughton deleted the sortable branch June 6, 2019 04:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants