Since the last upgrade v1.7 DE (self-hosted) when we duplicate a row the rows somehow ‘stay connected’ and get messed up when one of the duplicated rows is edited afterwards e.g. when we delete cell information from one row it also automatically gets deleted in the other. One time the whole base was even completely messed up, placing random cell snippets into random cells, which also happened after duplicating a bunch of rows.
Is there any sorting in this view? It sounds like when you change the content of a cell the row runs away, is the behavior of an active sorting.
If this is not the case, some screenshots might help us to understand the bug better.
This is very strange, can you give an example? Is it a linked cell that was deleted?
And - what exactly was messed up? Did you mean cell contents even “run” across columns?
I’d have to double check about the linked cells. As far as I remember it happened with both linked and standard cells. Messed up means that the whole table was completely mixed up, content appearing all over the place, in wrong rows, columns, everything. Obviously I’m not trying to replicate the error as we are in production and after the previous experience I’m avoiding duplicating at all costs. I can try and make a test table when I have more time at my hand and share some screenshots.
On a side note: Another strange behaviour that I observed has to do with being logged in and out. As long as I stay within the same base Seatable pretends that I’m still logged in (I can edit cells etc.) when actually I was logged out by timeout already. This is only indicated after refreshing the page or switching to the dashboard. This leads to changes and edits not being saved and lost information if one is not careful enough to refresh the page every time editing is done in a base. Very well possible that those two issues are related. I don’t know.
In the base page, an access token is used for reading/writing to the base, the token is valid for one day and refreshed using your browser session. Even if you logout your session, the access token can still work until expired. So as long as you don’t see an error that explicitly tell you a permission problem, your changes will be correctly saved by the server.
How did you duplicate a row? Did you use API?
Using the context menu:
The duplicate row bug is still existing in 2.0. I will try to illustrate the issue in more detail:
We are looking at the ‘Shots’ column of this table.
I’m duplicating the row with ‘Scene 3’ using the duplicate row context menu.
Then I add a new link to the duplicated row.
The previously added link also gets added to the original row. To reproduce you have to click the original row once (otherwise it’s not initially visible). Those two rows stay connected this way (every change you make in one also affects the other) until you delete all the contents from one and re-populate from scratch.
As mentioned before, in at least one case (grouped and filtered records combination I cannot remember) this behavior led to complete mixed and messed up records through the whole table (also rows that haven’t even been touched).
I finally could understand what this issue is, and have just reproduced it. Thanks for letting us know.
Is there actually a way to change the duration of the validity of the access token/cookie?