You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Essentially, if not using the generated cluster types for encode, they won't fabric filter if a MatchesFabricIndex method isn't provided. They also won't fail to compile or otherwise warn, so this is highly dangerous.
There is discussion in that conversation about various ways to address this. It should be addressed at the DM/IM level as appropriate, and then whatever changes need to happen to access control cluster (for whatever new mechanism is used for fabric filtered read) will have to happen.
The text was updated successfully, but these errors were encountered:
IsFabricScoped now requires "kIsFabricScoped" attribute always exists when encoding structs.
It says
* Using IsFabricScoped<X>::value without a basic type or cluster object with kIsFabricScoped will cause a compile error. This is
* an intended behavior to make users explicitly decide whether their cluster object is fabric-scoped or not.
See PR #13881 and particularly this conversation:
#13881 (comment)
Essentially, if not using the generated cluster types for encode, they won't fabric filter if a MatchesFabricIndex method isn't provided. They also won't fail to compile or otherwise warn, so this is highly dangerous.
There is discussion in that conversation about various ways to address this. It should be addressed at the DM/IM level as appropriate, and then whatever changes need to happen to access control cluster (for whatever new mechanism is used for fabric filtered read) will have to happen.
The text was updated successfully, but these errors were encountered: