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

Bug with field dependencies if dependent field is not visible/available #780

Open
jmartsch opened this issue Jan 7, 2019 · 16 comments

Comments

Projects
None yet
6 participants
@jmartsch
Copy link

commented Jan 7, 2019

EDIT:

for a better understandable description of the problem:
If the dependency of a field can not be checked, because the dependent field is missing/not available then don't run the check at all and don't hide the field that has the showIf condition.

original text

There is an error when a field dependency is needed, but only one of the dependent fields is available/visible to a specific role.

Please take a look at this video (with audio) where I try to describe the problem, because it is too complicated to write.

https://www.youtube.com/watch?v=gwFB9kIMcuo

Here is an export of the two fields:

{
    "bueroraum": {
        "id": 398,
        "type": "FieldtypeCheckbox",
        "flags": 224,
        "name": "bueroraum",
        "label": "",
        "label1019": "Büroraum",
        "collapsed": 0,
        "checkboxLabel1019": "Ja",
        "editRoles": [
            "laborplaner"
        ],
        "viewRoles": [
            "laborplaner",
            "sachbearbeiter"
        ],
        "showIf": "",
        "themeOffset": "",
        "themeBorder": "",
        "themeColor": "",
        "columnWidth": 100,
        "required": "",
        "requiredIf": "",
        "checkboxLabel": ""
    },
    "raumart": {
        "id": 107,
        "type": "FieldtypePage",
        "flags": 0,
        "name": "raumart",
        "label": "",
        "label1019": "Raumart/Raumnutzung (zukünftig)",
        "derefAsPage": 1,
        "inputfield": "InputfieldRadios",
        "parent_id": "/kategorien/raumart/",
        "labelFieldName": "title",
        "collapsed": 0,
        "optionColumns": 0,
        "showIf": "bueroraum=0",
        "allowUnpub": "",
        "defaultValue": "",
        "template_id": "",
        "template_ids": "",
        "findPagesSelect": "",
        "findPagesSelector": "",
        "labelFieldFormat": "",
        "addable": "",
        "themeOffset": "",
        "themeBorder": "",
        "themeColor": "",
        "columnWidth": 100,
        "required": "",
        "requiredIf": ""
    }
}

The solution would be, that even when the field "bueroraum" is not editable/and not visible, the if condition for the field "raumart" should work.

@Toutouwai

This comment has been minimized.

Copy link

commented Jan 7, 2019

Not sure this is really a bug, but more a requirement that is needed for inputfield dependencies to work that is not being met. Inputfield dependencies work by evaluating field values via Javascript - if the source field isn't present then the evaluation can't take place as expected.

In your specific case of a checkbox dependency you could try changing from bueroraum=0 to bueroraum!=1.

But a more general solution is to conditionally apply your inputfield dependency in a hook before inputfield render. E.g. if such and such a role, or if such and such a field is also present in the form, then apply the inputfield dependency.

@LostKobrakai

This comment has been minimized.

Copy link
Collaborator

commented Jan 7, 2019

The js could however be supplied with the static values of non-editable fields, so the js doesn't even need to search for form inputs in the first place.

@jmartsch

This comment has been minimized.

Copy link
Author

commented Jan 7, 2019

I turned on debugging for the dependency checks in inputfield.js and it turns out that if the dependent field (bueroraum) can not be found, the check is skipped and the field (raumart) is hidden.
image

I think it would be better if the dependent field can not be checked because it is missing, then the other field (raumart) should be shown, instead of beeing hidden.

However, if I select that the field bueroraum is "viewable" for the role (sachbearbeiter) and it appears, why does the check also fail?

@jmartsch jmartsch changed the title Bug with field dependencies if one field is not editable Bug with field dependencies if dependent field is not visible/available Jan 8, 2019

@ryancramerdesign

This comment has been minimized.

Copy link
Contributor

commented Jan 17, 2019

@jmartsch A showIf condition implies that the field should only be shown if the described condition is present and matching. When the variables needed to complete the condition are not present, it would be expected to resolve to false. If we were to change it to resolve to true, then it would break the logic. I'm assuming some are already be relying upon this behavior, so probably not an option to reverse that logic.

But I understand the behavior you are looking for here, and wondering if maybe it's a case for a having "hideIf" condition? i.e. "hideIf=bueroraum>0". Such an option doesn't currently exist, but it could. If this is a specific case you are wanting to resolve quickly, it might be worth using a hook to insert an a hidden field named "bueroraum" with id "Inputfield_bueroraum" and value "0" into the form when it is not present, so that your showIf condition can match. I'm happy to write the code to demonstrate what I mean, if it would help? Also happy to look into the potential for hideIf conditions, though that might take longer to develop.

@horst-n

This comment has been minimized.

Copy link

commented Jan 17, 2019

@ryancramerdesign I'm interested in the quick solution code with the hidden field insertion!

@jmartsch

This comment has been minimized.

Copy link
Author

commented Jan 22, 2019

@ryancramerdesign I agree with you. But in my example I also set the access level of the field bueroraum to "viewable" for the role "sachbearbeiter". So if it's viewable, it should be able to be checked.

@LostKobrakai #780 (comment) answer looks like the solution to me.
So there should be a data-attribute, span or whatever, that contains a static value of the to be checked field, if the field is viewable.

This would also not break the actual logic.

@netcarver

This comment has been minimized.

Copy link
Collaborator

commented Feb 15, 2019

@ryancramerdesign Just bumping this for your further consideration. Will review in a week.

/remind me to review this issue in 1 week

@reminders reminders bot added reminder and removed reminder labels Feb 15, 2019

@processwire processwire deleted a comment from reminders bot Feb 22, 2019

@ryancramerdesign

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

@netcarver @jmartsch I don't think this is one we can implement in a manner that will continue to scale. While we could resolve it for one type of Inputfield or another, the issue is that Inputfields are modules and PW core doesn't know anything about how simple or complex the data is for any particular Inputfield. Only the Inputfield knows that. Without any input elements present for something, there's nothing for dependencies to examine from the JS side. Maybe a data attribute would work for one case, but it wouldn't scale beyond the very simplest cases. I don't want to build in something that might work for single-line text or number fields but then wouldn't work for others.

What I would suggest is that for cases where you need it, use a hook to provide an input elements for the dependencies. One way to do it would be to have the Inputfield::renderValue() method call the Inputfield::render() method, but wrap it in a div that's hidden or something. A hook like this in /site/templates/admin.php might do the trick:

$wire->addHookAfter('Inputfield::renderValue', function($event) {
  $inputfield = $event->object;
  $event->return .= "<div style='display:none'>" . $inputfield->render() . "</div>";
}); 

I've not tried this, but theoretically it could work. This would hook all visible-and-not-editable Inputfields, so once you've got it working, you may want to want to limit it to just those you need by specifying InputfieldSomething in the addHook call or filtering $inputfield->className() from within the function. Once working, you might also want to add the following to the top of the hook function to prevent this from affecting other instances of Inputfield renderValue() calls, outside of the Page editor:

if($event->wire('process') != 'ProcessPageEdit') return;

@processwire processwire deleted a comment from reminders bot Feb 28, 2019

@reminders reminders bot added the reminder label Feb 28, 2019

@reminders

This comment has been minimized.

Copy link

commented Feb 28, 2019

@netcarver set a reminder for Mar 14th 2019

@reminders reminders bot removed the reminder label Mar 14, 2019

@reminders

This comment has been minimized.

Copy link

commented Mar 14, 2019

👋 @netcarver, review this

@netcarver

This comment has been minimized.

Copy link
Collaborator

commented Mar 14, 2019

@jmartsch Jens, any thoughts on Ryan's post above?

@jmartsch

This comment has been minimized.

Copy link
Author

commented Mar 14, 2019

@netcarver Have to check this. Sorry, I am sick atm and had not much time to check.

@netcarver

This comment has been minimized.

Copy link
Collaborator

commented Mar 14, 2019

No problem - hope you get well soon.

@jmartsch

This comment has been minimized.

Copy link
Author

commented Apr 18, 2019

/remind me to review this issue in 1 week

@reminders reminders bot added the reminder label Apr 18, 2019

@reminders

This comment has been minimized.

Copy link

commented Apr 18, 2019

@jmartsch set a reminder for Apr 25th 2019

@reminders reminders bot removed the reminder label Apr 25, 2019

@reminders

This comment has been minimized.

Copy link

commented Apr 25, 2019

👋 @jmartsch, review this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.