This is the continuous of this forum topic. Other than transplanting logs not reflecting for group members.
If other than any issue(related to group logic) please note it in this form topic
Thank you.
Thanks for starting this thread @aathi179!
One of the biggest questions to figure out first is how to display these logs in the UI. Should they be mixed in with logs that reference the group member assets directly? Should there be a filter to include/exclude them? Should they be marked somehow to make it obvious that they are “indirect” logs instead of “direct” logs? Or should they be displayed in a separate page/tab/list entirely?
This might be a good user design question: where would you expect to see these logs? Inline amongst the asset’s other logs? Or in a separate list?
From a technical perspective the biggest challenge is the SQL query. The current lists of logs associated with assets are very simple SQL queries created via the Views module. Querying logs on behalf of the group adds a layer of complexity. This might be reason to start with them in a separate page/tab/list (a separate View) rather than trying to display them inline with “direct” logs.
Assets can change group membership over time. This means that we not only need to query for logs that reference the group that an asset is currently in. We need to query for logs that reference the group that the asset was in at the time of the log.
The other technical challenge here is that we need to support a query that works on PostgreSQL, MariaDB/MySQL, and SQLite3. In farmOS v1 we had some complicated queries for asset location which only worked with MariaDB/MySQL. We simplified those in v2 (with some tradeoffs) to ensure compatibility.
One thing that I’ve thought about doing for a long time is changing the way that location and group logic works, such that we maintain an “index” database table alongside them that “caches” the computed location/group membership of assets at a given point in time. This would make queries very easy, because we could query that table directly rather than computing things on the fly. This will probably be inevitable in the long run, if performance is affected over time as more and more logs are added (although maybe for location/group membership that won’t be an issue in practice).
In either case, it might be worth considering a “cache” table of some kind for the purpose of tracking asset group log associations, in order to simplify the query, and perhaps make it easier to include those logs amongst the “direct” asset logs. 
Thank you for sharing more perspective parameter. This week i am taking to understand code (before Monday). Then i will come back.
Thank you for giving opportunity.
There was some discussion years ago about group logic as it relates to logs here Group membership logic, V2 - #7 by mstenta
Thank you. I will look.