This PR adds another strategy for resource instance filtering. Core Arches does this by storing Guardian permissions objects for every instance of a resource being hidden from a user. In our current production database this would create about 28 million objects (in just one of the guardian models), and this would increase by the number of users (~800 and growing) each time a new archaeological site is added to the database. So, 1,000 new sites, 800,000 new permissions objects.
To avoid this overhead and potential performance issues down the road, a new strategy is implemented here which stores one object (in the new UserXResourceInstanceAccess model) for every occurrence of a user being granted access to a resource instance. An FPAN regional account may generate a few thousand objects, but scout accounts only a few. This table can then be referenced by search-related operations to speed up access checks to resources.
A new method/trigger is added to the Land Manager profile which updates the UserXResourceInstanceAccess table every time the profile is saved.
This method uses the SiteFilter to figure out which resource ids to add to the table.
A new function is added (to be associated with the Archaeological Site resource model) that will be triggered every time a new scout is assigned to a site. This function adds/deletes entries in the UserXResourceInstanceAccess as needed.
E-mail notifications to scouts could also be added in this function (#37)
In the SiteFilter, a new experimental method is added to pass a set of resource ids (obtained from the UserXResourceInstanceAccess table) directly into the ES query, instead of running the actual spatial query. This is only implemented for the new Land Manager accounts.
Similarly, in the api.MVT class, this same strategy is used to acquire the resource ids that are passed into the SQL query.
contributes to
Land Manager Account Overhaul task.
This PR adds another strategy for resource instance filtering. Core Arches does this by storing Guardian permissions objects for every instance of a resource being hidden from a user. In our current production database this would create about 28 million objects (in just one of the guardian models), and this would increase by the number of users (~800 and growing) each time a new archaeological site is added to the database. So, 1,000 new sites, 800,000 new permissions objects.
To avoid this overhead and potential performance issues down the road, a new strategy is implemented here which stores one object (in the new UserXResourceInstanceAccess model) for every occurrence of a user being granted access to a resource instance. An FPAN regional account may generate a few thousand objects, but scout accounts only a few. This table can then be referenced by search-related operations to speed up access checks to resources.
In the SiteFilter, a new experimental method is added to pass a set of resource ids (obtained from the UserXResourceInstanceAccess table) directly into the ES query, instead of running the actual spatial query. This is only implemented for the new Land Manager accounts.
Similarly, in the api.MVT class, this same strategy is used to acquire the resource ids that are passed into the SQL query.
contributes to Land Manager Account Overhaul task.