Version 4.4 of SeaTable Server is now available. It can be downloaded from the well-known Docker Hub repository.
And we didn’t waste any time making the release’s numerous feature additions and improvements available to our cloud users: SeaTable Cloud was updated this morning 6 am CET.
The following highlights are available to Free, Plus, and Enterprise subscribers:
Improved page types in universal app builder: Build powerful dashboards with more design options on custom pages, handle data on table pages faster thanks to new mouse actions, use collaborator columns in form pages, drag and drop records on calendar pages, and allow user interaction on query pages with buttons
Supercharged Excel import: Select the sheets to import from your XLSX-workbook and start working on the data much faster than in the past
Common dataset push sync: Force the synchronisation of your common dataset to ensure your partners use the most up-to-date data
Sync common datasets with existing tables: Resync tables in bases that you created from a template or that you restored from a snapshot
„Sticky“ links to common datasets: Copy bases and retain the link to the common dataset in the new bases
Universal default values: New rows are populated with the defined default values no matter how new columns are created – manually or via a form, button, or automation.
As announced, SeaTable 4.4 says „good bye“ to the gallery app builder and replaces the „old“ data query app builder with a new one based on the universal app builder.
You find the Release Notes for SeaTable 4.4 in the SeaTable Blog. For those of you that want more details, you find all changes – as always – in the Changelog.
I feel like the new version also introduced some API changes, because we started having issues with dates (has the return format changed?) and also duplication of records (get_row and then append_row) - I will come back when I have more details
In addition, the API gateway also harmonizes and improves all dtable-db and dtable-server endpoints. But all former endpoints stay alive and can still be used. Look at our API documentation at https://api.seatable.io, you will find all new and former endpoints.
Long story short:
if you observe changes in the output, please return to us. This should not be the case and we will fix this.
you don’t have to switch to the new API endpoints. The old endpoints are still valid.
some clients require an additional parameter to follow the redirect. In case of curl, you have to add -L to the command.
Thanks a lot for your help and explanations!
The differences I noticed are
dates coming via List Rows (v1 endpoint) are now formatted string with the setting as configured in the table (in our case “German” format dd.mm.yyyy) and previously were always coming as ISO date strings
Get Row with row_id returns nothing now for existing IDs in an untouched implementation. The api.seatable.io website works however as expected using v1 endpoint.
EDIT: I see that v1 endpoint for Get Row is doing a 302 redirect to the v2 endpoint and our implementation wasn’t following the redirect. So as both endpoints seem to be equivalent switching to v2 endpoint or dealing with the redirect solves the issue.
I apologize, if the date format changed, that was not our intention. I will clarify that.
Regarding your second point, I already answered this in my last answer:
I assume that your implementation of the API does not follow redirects and therefore delivery zero output.
It was not our intention to generate breaking changes in the API. Therefore, just one hour ago, I deactivated the redirect of the calls Get Row and List rows to the new API-Gateway. As a consequence, the API should now behave like it did in the past.
We will re-activate in the future these redirect after we made sure that the output of the API does not create breaking changes. The necessity that the clients support redirects will be activated most likely in the future again.
I am sorry for these changes. Please check your scripts and integrations that they work as they should. I keep you updated.
Unwanted changes happen and it’s outstanding that you acknowledge and address them so quickly. For our part the issue was identified and fixed in a day by following the redirect and dealing with the date format. The seatable_ruby gem has now a new branch to support the v2 endpoints. It will be merged into main when we have tested a bit more.
