OK, yes the issue is exactly as I suspected. The full explanation and workarounds can be found in this thread:
I don’t follow everything here, but if there is a widget on the marketplace with a “problem” in recent versions of OH, maybe the author should be notified? Two versions can easily be hosted by using version ranges in the title so that the “old” version that works on older systems can remain available for them, while an updated version is available for more recent versions of OH - if the problem is of that nature.
It’s not exactly. The widget itself works just fine. The problem is that when using an OH list widget it actually references it’s parent widget when determining whether or not to render an accordion list. In the widget editor the appropriate info has been added to the overall context so that you can test out list widgets without having to put them in a fake list in the editor (which was the case for many years). This is also not a problem when you are adding this kind of widget to your own list component where you can set the relevant property in the list yourself. It is only a problem in the one instance where you try to use an item widget as an accordion item as a default list widget because then it winds up in lists that don’t have the required parent property.
If accordionList: true were added to every list where default list items get rendered then this would fix this one edge case as well. Also, if all the oh item components were refactored to not require the parent level check, that would fix this plus other related issues (for example trying to use a repeater to add multiple accordion list items to a list).
But, there are reasonable (IMO) workarounds as outlined in the link above and I don’t know if there would be other downstream issues to such a universal changes so I haven’t taken the time to pursue the issue any further.
As always with these things, I lack sufficient details to really understand the situation, but if you could give me some hint about what check this is, I might be able to figure something out.
What is a reasonable workaround for you can easily be an unsurmountable obstacle for others 
To simplify the f7-list-item accordion configuration for the oh-list-item, Yannick included the above logic. This means that an oh-list-item will only render its accordion slot components if its parent has accordrionList set to true. The original assumption was that the parent component will always be a list component where the user can set that accordionList property. This still works most of the time and only fails in two instances 1) the list item is added to a list that the user cannot configure such as semantic card lists (which is the case here), or 2) the immediate parent of the list item is not the list itself, but an oh-repeater or oh-context. Sitation 2 is of 0 consequence because there is no penalty for just also adding accordionList: true to the repeater or context component and the logic works again.
For me, this is nothing more than a trivial speed-bump. However, from my extensive experience helping other OH users, the various workarounds are at a level it is reasonable to expect someone starting to build more complex accordion widgets can handle (or is a good exercise to help them jump to that next level).
With the danger of “stepping in it” since I don’t know these things well enough, I made this change, which makes the accordion work:
.../web/src/components/widgets/standard/list/oh-list-item.vue | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/bundles/org.openhab.ui/web/src/components/widgets/standard/list/oh-list-item.vue b/bundles/org.openhab.ui/web/src/components/widgets/standard/list/oh-list-item.vue
index 5e0a9336..c490b2b4 100644
--- a/bundles/org.openhab.ui/web/src/components/widgets/standard/list/oh-list-item.vue
+++ b/bundles/org.openhab.ui/web/src/components/widgets/standard/list/oh-list-item.vue
@@ -182,7 +182,8 @@ export default {
return this.context.parent.component.config.accordionEquipment && this.accordionSlots.length > 0
},
isRegularAccordion() {
- return this.context.parent.component.config.accordionList && this.accordionSlots.length > 0
+ if (this.config?.accordionItem === false) return false
+ return (this.config?.accordionItem === true || this.context.parent.component.config.accordionList) && this.accordionSlots.length > 0
},
accordionSlots() {
if (!this.context.component.slots?.accordion?.length) return []
As far as I can tell, oh-list-item doesn’t check the accordionItem configuration property at all. Instead, it only looks at the parent. My change makes it behave like this:
- If
accordionItemisn’t specified, it behaves as today, according to the parent. - If
accordionItemis set totrueand it has at least once accordion slot, it will be an accordion. - If
accordionItemis set tofalse, it won’t be an accordion regardless of what the parent says.
Would this break anything? Would it be bad to be able to “deny accordion” for specific items even if the parent says “you are accordions”? Is there still a shortcoming here in that you can only define it for custom widgets, or isn’t that a problem?
many thanks to both of you for your inputs. Just to confirm, I am running openHAB 5.2.0.RC1 and I am going to switch to the release version. Maybe this fixes the issue, as Justin says that it is working for him. But since this topic is already around for few months, I think this is either a regression or the fix has not yet been pushed into the release.
I happily support Nadar’s suggestion above. I cannot assess the implications, but from the code snipped and his explanation, I feel it makes sense. This is probably a better solution than to tweak the widgets for a workaround.
Have a great day!
Michael
I’m not sure why anything would have changed regarding this in the release version, is there really a regression here? I thought that had been the behavior for years?
My suggestion would make it possible to override what the parent says. As far as I can tell, setting accordionItem on the list item itself has no effect as the code is today.
I haven’t created a PR because I can’t properly assess the implications it would have, if any. I just don’t know how to properly evaluate that. @JustinG Do you have any input on that part?
Sorry, I’ve been traveling. This doesn’t look like a destabilizing change, but as I said above, one of the reasons I haven’t addressed this before is that I’ve never taken the time to look through for downstream issues. My guess is that this is fine.
Can you think of situations where accordionItem is already set on oh-list-items today, because it appears to me like it isn’t used, but this would suddenly make it have consequences? That could potentially break things if it is for some reason set anyway…
No. I am not aware of any situation where accordionItem on an oh-list-item is functional at the moment.
Not functional, I’m pretty sure that it’s not, but could it be set anyway, which would wreak havoc when it starts being honored? I could choose another name for it to avoid potential conflict, but that makes it “less logical” for people to know about/use as well.
I agree choosing a different name is not the right approach.
I could construct theoretical scenarios where someone has it set on an oh-list-item (e.g., left over from an attempt to use and f7-list-item) but none of them lead to undesired behavior with your change; if it’s set to true the user should want to see the accordion content rendered. I don’t think you really need to worry about the exception where, for some bizarre reason, a user has set accordionItem to true and has components in an accordion slot but somehow doesn’t actually want to render an accordion list.
Ok, PR created, now it’s in the hands of the maintainers if they want it or not:
The PR has actually been merged already, but it’s destined for 5.3, so you won’t be able to use it anytime soon, unless you install snapshot versions (which I wouldn’t recommend).