Show erasure status when listing users in the Admin API

[tadzik]

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Pull request includes a sign off
• Code style is correct
  (run the linters)

[dklimpel]

Is there a significant impact on performance with an additional left join on a large list?

[DMRobertson]

We have a query plan here: #14205 (comment)

There is a sequential scan mentioned under the sorting section, but that mentions the profiles table only, which we already join to before this change. I have a suggestion here: will raise an issue.

[DMRobertson]

#14254

[dklimpel]

I have two thoughts on this:

1. There should be an update of the documentation.
2. Perhaps a unit test should rather be in UsersListTestCase than DeactivateAccountTestCase. This PR is more a modification of the list user API than the deactivate user API.

[DMRobertson]

I haven't checked the query changes or their performance characteristics. (Do we have a query plan for the new query?)

Does the erased field exist on the query user (singular) endpoint? If not, does this change add one?

As Dirk says, we'd also like to see the docs updated, please.

[tadzik]

I haven't checked the query changes or their performance characteristics. (Do we have a query plan for the new query?)

We have now:

                                                     QUERY PLAN                                                      
---------------------------------------------------------------------------------------------------------------------
 Limit  (cost=47.17..69.95 rows=100 width=145)
   ->  Merge Left Join  (cost=47.17..195.22 rows=650 width=145)
         Merge Cond: (u.name = (((('@'::text || p.user_id) || ':'::text) || 'home.tadzik.net'::text)))
         ->  Merge Left Join  (cost=0.30..128.90 rows=320 width=112)
               Merge Cond: (u.name = eu.user_id)
               ->  Index Scan using users_name_key on users u  (cost=0.15..52.95 rows=320 width=80)
               ->  Index Only Scan using erased_users_user on erased_users eu  (cost=0.15..68.55 rows=1360 width=32)
         ->  Sort  (cost=46.87..48.49 rows=650 width=96)
               Sort Key: (((('@'::text || p.user_id) || ':'::text) || 'home.tadzik.net'::text))
               ->  Seq Scan on profiles p  (cost=0.00..16.50 rows=650 width=96)

Does the erased field exist on the query user (singular) endpoint? If not, does this change add one?

No, and it'd indeed make sense to add it here as well.

As Dirk says, we'd also like to see the docs updated, please.

Right, I'll get on with it.

[tadzik]

Status added for single user endpoint in 84f27cf

Documentation added in 576bc65 – does that still need to be done in two separate places? I only found the matching strings in docs/admin_api/user_admin_api.md, but I recall there was some other source of truth out there as well.

[DMRobertson]

Other than signposting comments in the test I think this is good to go, thanks!

[DMRobertson]

We have a query plan here: #14205 (comment)

There is a sequential scan mentioned under the sorting section, but that mentions the profiles table only, which we already join to before this change. I have a suggestion here: will raise an issue.

[DMRobertson]

Assuming the complement failure is a flake (#14256).