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
When the React component powering /groups/<group>/audit updates (calls the API), the order of items in the table will sometimes change. This happens when sorting by "Started", but may happen with other types of sorts as well.
Here is the same page, after waiting 5 seconds between each screenshot. Note that the first two columns have swapped (it's more obvious when the redacted information is shown, but you can see the "member or owner" values are opposite after the update).
I looked at the responses from api/audit/users?group_id=<group>&page=0&per_page=20&order_by=created_at&order_desc=true, and it looks like the API itself returns a different order for each call (even though the URL parameters are the same and no additional audit entries have been created). So this may be a bug in how data is fetched from the database. I am not sure if it happens for other audit pages.
This is annoying when trying to review audit information to spot when someone lost access, as multiple rows are usually affected and swap at the most inconvenient of times.
The text was updated successfully, but these errors were encountered:
When the React component powering
/groups/<group>/audit
updates (calls the API), the order of items in the table will sometimes change. This happens when sorting by "Started", but may happen with other types of sorts as well.Here is the same page, after waiting 5 seconds between each screenshot. Note that the first two columns have swapped (it's more obvious when the redacted information is shown, but you can see the "member or owner" values are opposite after the update).
I looked at the responses from
api/audit/users?group_id=<group>&page=0&per_page=20&order_by=created_at&order_desc=true
, and it looks like the API itself returns a different order for each call (even though the URL parameters are the same and no additional audit entries have been created). So this may be a bug in how data is fetched from the database. I am not sure if it happens for other audit pages.This is annoying when trying to review audit information to spot when someone lost access, as multiple rows are usually affected and swap at the most inconvenient of times.
The text was updated successfully, but these errors were encountered: