ramil g → created an issue.
ramil g → made their first commit to this issue’s fork.
ramil g → created an issue.
ramil g → created an issue.
The Global: Calendar Header (Global: Calendar Header) is responsible for displaying that. It's in the Header section. I'm not sure how yours is configured, but see my attachment to see an example of one that works.
ramil g → created an issue.
ramil g → made their first commit to this issue’s fork.
ramil g → made their first commit to this issue’s fork.
ramil g → created an issue.
ramil g → made their first commit to this issue’s fork.
Added the test.
ramil g → made their first commit to this issue’s fork.
ramil g → made their first commit to this issue’s fork.
I ran into this as well. A tagged release would be nice.
Closing as a duplicate.
ramil g → created an issue.
ramil g → created an issue.
ramil g → created an issue.
@Vivek, thanks for adding your comment. Sorry, yes the shs field does need to be required, I forgot to mention this above - I have updated the description. And yes there is this weird thing that happens where if you don't touch the dropdown and just have nothing selected, in the code the value shows up as an empty string, but if you just select something else, then change it back to the default, this changes the value to '_none' in the code. We noticed that if you are using Select2, this doesn't happen, the original value is set to '_none', and not ''.
This is why in my patch, in line 345, I had to add a condition to check if the value is empty to account for this: https://git.drupalcode.org/issue/shs-3427207/-/commit/3e4adfff57cb65db45...
@abhishek - thanks for adding a patch but I actually did upload a patch yesterday but I used the new way of doing it, which is using git to commit to add the patch instead of uploading a patch file. You should see it above where it says "Issue fork shs-3427207"
ramil g → created an issue.
Thanks for reporting this @very_random_man and thanks for that info. I think you're right, it does need a check to make sure it's an inline entity form. We've implemented this in this new patch.
We're experiencing something similar. Can you try disabling the caching for the embedded view?
ramil g → made their first commit to this issue’s fork.
For anyone interested, here's a patch that does this:
https://www.drupal.org/project/conditional_fields/issues/3399173
✨
Compatibility with shs module
Needs review
This is for the 4.x version (Drupal 9 & 10)
This patch makes conditional_fields work with the shs module.
ramil g → created an issue.
Tested this patch and it works. Changing this to RTBC.
This patch gets it working for us.
Inside the getState method of ConditionalFieldsFormHelper, when you use $form_state to grab the entity , it gives you the entity from the main form, rather than the entity inside the inline entity form (the entity being referenced). This patch fixes that.
Just uploading another patch that fixes a part in afterbuild where it wasn't getting the right entity bundle.
Does this patch work for anybody out there? It's currently not working for us, and we're working on getting it to work. Just curious if there's anyone out there that this patch is working for.
Here's a re-roll of patch #83 for the latest 4.0.0-alpha5 release.
Here is a patch for it.