-
-
Notifications
You must be signed in to change notification settings - Fork 824
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
Add CRM_Core_Form::isFormInViewMode and CRM_Core_Form::isFormInEditMode #17637
Conversation
…sions implementing buildForm)
(Standard links)
|
@mlutfy Not blocking and happy to merge. But does it make sense to have |
@mattwire Maybe it's lazyness on my part, but I mostly need a way to avoid running buildForm code during a deletion, and that function seems to work for most use-cases. (Form View is still a normal form, just usually frozen, and BROWSE/BASIC/ADVANCED/PREVIEW are rarely used). |
OK, pushed an update :) |
As an aside the 'ready for review' tag should probably be added by someone other than the PR submitter. The fact the PR exists & doesn't have [WIP] in the header means the submitter thinks it's ready. The tag should indicate someone else does as well |
Makes sense - although it's not easy to see PRs where feedback was given, and the author responded. Then again, most authors can't add tags, so it makes sense to keep this tag for reviewers (and not self-tag). |
@mlutfy That's what I created the tag for and intended it be used for. I add it on my own PRs and others in exactly that situation. |
Is the function contents mismatch going to be confusing? I would expect from the wording that if someone were to refactor
that it would be identical, but that wouldn't always be true here. Is there a reason for leaving out BASIC etc? You said they're not often used, but are they never used when this is called? |
Yeah - the thing about 'ready to review' is that it can't be added by un-permissioned users - whereas pings & 'request review ' can & it implies that these ones are ready & others are not. I don't personally factor it's existence or not into whether I look at a PR - since I haven't found PRs tagged with it as any more ready-to-review than others , but some people may do. |
Perhaps we should automatically tag ALL PRs as 'ready for review' & then we can REMOVE the tag if it turns out not to be? I think I might find it useful if that were the case |
@mlutfy I've removed the MOP because there is feedback by @demeritcowboy - can you check that out respond to it. |
@mlutfy also - please self-merge this if you can agree it with @demeritcowboy - I don't think we need further involvement by others as whatever you & @demeritcowboy agree seems fine in this context |
89f7446
to
99dfc0b
Compare
@demeritcowboy Good point - I think those actions were added for "action links", and most of them are basically a type of "Edit" mode. I updated my patch. |
…ode (useful for extensions implementing buildForm)
99dfc0b
to
189701b
Compare
Thanks looks good. As per earlier comments "merge on pass". |
Thanks! It's a really minor detail, but I often get bit by this in extensions. It'll make things cleaner! |
Overview
Extensions implementing the buildForm hook often have to make sure that
$form->elementExists()
before applying a certain logic, otherwise QuickForm will throw a fatal error if the field is missing.Sometimes we use it as a lazy way of checking the mode of the form, which we can get through
$form->getMode()
and then try to remember which of theCRM_Core_Action
constants we have to check against.I stumbled on
CRM_Core_Form::isFormInViewOrEditMode
and found it rather practical, but it is set as protected, so we cannot call it from a buildForm hook, which has$form
, not$this
.Comments
The function was added in 2018-01 as part of 240b0e6, which is fitting. I stumbled on a similar bug in an extension just now, while trying to delete a profile field.