Amazing, I had tried that during my troubleshooting and ruled it out, but I must have made a mistake somewhere because I tried it again this morning and it worked perfectly.
@rdb - for #3, I am in the America/Edmonton timezone. My server and computer are both set to the same timezone. My ‘fix’ works fine, but during my troubleshooting I found a new bug. I turned on the “accurate to minute” toggle, which I previously had turned off. That shifted everything in the calendar back one day. When I turned the option off, the date in the column was now moved back one day. Every time I turn the option on, then off, all dates in the column shift back by one day. Perhaps the way the calendar and the date column interpret dates/times exactly at midnight could be the issue?
Also, one more comment, perhaps related to the calendar issue #3.
When I have a date column with a date (say - 2021-05-03) and I use the formula “dateAdd({Date}, 1, “days”)” in a formula column, the result is the same day (2021-05-03). If I use “dateAdd({Date}, 2, “days”)” I get the next day (2021-05-04). This is all with the “Accurate to minute” turned off, and I use the ISO date format.
in SeaTable 2.0, we fixed your #4. Can you confirm?
As for #2, SeaTable 2.0 also adds optional default values for text, number and single select columns. We may add default value options to other columns too. (But it’s a 2nd order priority.)
Could you solve your #7 with Karlheinz?
Is #6 still a problem?
The big mystery is #3. We haven’t had time to investigate the problem in greater detail due to 2.0. But it’s on our list.
Hi Ralf, thanks for the follow up, I’m looking forward to upgrading to 2.0 next week.
For #7, this has been resolved. It looks like there is some kind of ‘directionality’ in the linkID which is not transparent, and the correct ordering of the parameters depends on this direction. Maybe a documentation fix would help clarify.
For everything else, I’ll let you know after I try out 2.0!
Indeed, linking is directional. Once a link column is created, a “direction” is also defined in this column, from the “source row” to the “destination” row.
#3 is not fixed, so I am still using a second column which adds 1 to the date as the date field for the calendar plugin. I am also still having the issue where, on a date column, with ISO format, turning on “Accurate to Minute” then turning it off again decrements all the dates in the column by 1 day. Not sure if it’s related but both issues seem to point to handling of times exactly at midnight.
Ok, great! Thanks for getting back and confirming.
Going through this topic, it understand that
#2 (request) has been (partly) taken care of
#4 (bug) has been fixed
#6 (bug) has been fixed
#7 (bug) could be solved with Karlheinz
#8 (request) has been added
This leaves us with #1, which, for me, falls in the category of constant optimization, and #5 as a 2nd order priority feature request. We’ll keep those in mind, we won’t follow up on these two in this thread. Hope this is ok.
And, ultimately, there is the big mystery #3 which we have on the high priority list. We’ll get back to you.
Hi Peter,
I wanted to come back to your feedback from April 2021 and summarize the current status: #1 (request): You can show all records with the (actually not so new) expand icon. #2 (request): The current version has default values for text, number, single select, rating, and long-text columns. The date column will get static and dynamic default values with the next release, scheduled for release next week. #3 (bug): Could you please check if this post provides an explanation for your observation? #4 (bug): fixed #5 (request): this is on our long-term roadmap #6 (bug): fixed #7 (bug): fixed #8 (request): Script support is available in both self-hosted edition
If you agree, I will close - or actually you can close - this thread. #5 has been noted as a feature request and I don’t think it makes sense to keep this post open just for thie one aspect.
I’m happy with the suggested work-around, but this sounds like a great improvement
The post helps explain the behaviour. I still think this could be improved. For example, when I use a date column and put on a filter for Date Is Today, I have discovered through trial and error that it only shows me entries that are before today before 17:00, because of my local timezone. The Date column does not display a time, so what appear to be identical values get filtered differently. Note that in this case I’m populating the date field via the API with an input that does contain time information, which explains the unpredictable answers when I used the dateAdd function.
Related to this, I still have the issue where turning on, then off, the “accurate to minute” toggle changes the date, see the attached screen capture.
Fixed!
Great, still really looking forward to this one.
Fixed
There is still a problem here, but I have a workaround. If I write javascript to add a link, it never works on the first try, running the code produces an error. But, if I then add a link using the API to that specific link column, just one time, the javascript link function (with no changes to the script) works perfectly from then on. So making that one API request has just become a step for me to make a new script that does linking.
Thanks, I haven’t tried it yet due to the relative complexity of setting it up, the javascript is working fine, so far I can live without the schedule-driven execution although it would be nice.
@Karlheinz , here is the error message shown within the script editor:
and here is my script:
Once I execute the same operation using the API (copying the linkID and row IDs from the pop-up, into the curl command copied from the API reference) the code above works perfectly. I only have to do the API request once per linkID, from then on the script is fine.
What Peter reported is a known issue since a long time.
The issue is called “JavaScript: base.addLink only works after a link has been manually created”. It is reported on May 2nd, 2021. @daniel.pan would you mind having a look?
