Bug: Manual sorting in Views grouped by link columns confuses App

User Talk Apps
1

Your Setup:

  • SeaTable Cloud 6.2.x (current), verified on 6.0.x, 6.1.x and 6.2.x self-hosted

Describe the Problem/Error/Question:

Way to reproduce

  • Create a base with 3 simple tables (mine: Main, Second, Third)
  • Create link columns from “Main” to the other 2 tables
  • Link them liberally from “Main”, so groups of “Main” records are formed that share the same links to “Second” and “Third”
    • Maybe one secondary table is sufficient, but this is closer to the real life example where this occurred
  • Both in the backend table “Main” and in a universal App, create 2 unsorted Views / App table pages:
    • One flat view / table page: No Grouping, Sorting etc.
    • One view / table page grouped by the “Second” and “Third” link columns

The result should look like this (I also have a example base on Seatable Cloud I could share)

grafik
grafik741×434 13.7 KB

Two steps to provoke the bug, and verify its cause:

  • Normal behaviour: In the backend’s flat list, manually sort two entries (I swapped “One” and “Two”)
  • Faulty behaviour: In the backend’s grouped list, manually sort two entries (I swapped “One” and “Two” back again)
    • Correct result: In the backend, the order is correct in both views
    • Faulty result: In the App, total chaos breaks loose (see below)

This is what I can see:

  • In the manually sorted (moved) record, the linked columns seem to be empty in the App.

  • Accordingly, the record is now in a (empty)(empty) group in the App.

    grafik
    grafik318×203 1.79 KB

  • However, everything is still correctly linked in the backend.

  • Therefore, all efforts to re-link “Main” to “Second” and “Third” fail in the App, because the links are still there, but not shown in the App.

  • Remedy: Removing the content of the 2 link columns of the affected record in the backend (or the app?), and re-linking them correctly will restore the correct behaviour.

If you ask me, some mechanism in the manual sort algorithm that tries to retain the grouping messes up the link columns.

Edit: How can I give someone at Seatable Gmbh access to the example base?

2

Thanks for the detailed bug report.

You can send

3

@rdb thank you! A mail has been sent.

4

Hi @abaer,

thanks again for the example base. We were able to reproduce the issue on 6.2.13 and found the cause.

When you drag a row in a view that is grouped by link columns, SeaTable sends a “move group rows” operation. The base itself handles it correctly (that’s why the links still look fine there). But the database layer that feeds the Universal App and the API interprets the same operation as “set the link columns to empty”. So the base and the app end up out of sync. The row lands in the “(Empty)” group in the app, and re-linking doesn’t help because from the base’s point of view the link already exists.

This is now with our developers. Until it’s fixed:

  • Avoid manual sorting in views grouped by link columns. Sorting in a flat (ungrouped) view is safe.
  • To repair an affected row, remove the link and add it again — that writes a real link change and brings the app back in sync.

The same inconsistency also affects the API and SQL queries, not only apps, so it’s worth fixing rows you know are affected.

Best regards
Christoph

5

Thanks for researching this, looking forward to the fix. In the meantime, we’ll just avoid manual searching at all in such a scenario.

Sorting the flat list is not an option due to the length of the view. Pre-sorting (instead of grouping) by the link column seemed to be an option, until I remembered that any sorting completely turns of manual sorting.

At least that was the state when I checked last. If this is still the case, did you ever consider an old suggestion: If any sort order (e.g. by year: 2025, 2026, 2027) returns multiple records with identical search criteria (5 records with 2025), Seatable should sort those by their manual sort order if present?

My last knowledge was that the order of those 5 records would be determined randomly/by creation date / last modification?