Hosted Feature Layer View - filter related table records by parent filter?

[ChristopherCounsell]

Hi,

I have a Hosted Feature Layer with a point and related table layer. We want to work with certain points and only the related table values for these points

Creating a Hosted Feature Layer View and applying a filter to the point layer (e.g. objectid=1), ALL related table values still persist in the table. 

This is an issue as users can access the full related table when we only want them to see records related to the filtered points e.g. via REST, item page, table widgets, show ALL related records, not just those for objectid=1.

Is there a way AT A VIEW level we can have the related records filtered by the parent point layer query? 

Thanks

[MobiusSnake]

Here's an ugly workaround I've used for this, in cases where new data comes in from Survey123.  It might be less ugly with more static data, haha.

In my schema, I have a 0/1 integer field named something like "processed" on the main layer and all related layers/tables, by default this is set to 0.  I then have a "parent ID" on all child tables, set to null by default.

I have a notebook which runs every couple hours or whatever that looks for records with a processed value of 0.  If it finds any, it copies the parent's ID to the child records, then sets all the processed values (parent and child) to 1.

My views have a filter that doesn't allow anything to be shown unless processed = 1, then I can add additional filtering based on parent IDs.

It certainly isn't pretty but it works well enough.

[ChristopherCounsell]

Thanks @MobiusSnake. If we are using a point-level filter like region=a for one view, region=b for another, we could copy this into the related records and apply the same filter on that table. a script or survey could add the matching region value for the parent.

However if the end user reassigns the point from a to b, the existing related records would not come across but would remain accessible in the other view.

The tool could be updated to periodically check and update all related values but that's a chunk of processing we'd like to avoid if possible. Also extremely difficult to implement for more complicated filters.

It's interesting as deleting points from a map deletes the related records, but making a filter doesn't hide them. Seems like a bit of a gap in the logic to me. If it's not possible, probably going to be an idea/enh.

[MobiusSnake]

Yeah my approach definitely falls over if the values being used are editable later in the game.

Webhooks could be another approach, have something set up so if any of your filter-related fields are updated (along with at feature creation time), your webhook calls a function that propagates those values to the related tables.

That seems like way more work, complexity and processing than what it should require though.  A "Hide Orphan Records" on/off property on each child table in a view would be way better.