I have a PM project template that has been used in other projects and cleared out (by removing all table rows and then duplicating the document to remove the change history from the history views).
Is there a more explicit way to reset a document? Specifically I’d like a way to clear history of a table to reset it to a clean state, e.g. rowId() of the first row would return 1.
Currently a new project using my template starts with rowId() around near 1000, which is not ideal if I’m going to be using them for things like pull requests.
You can highlight a table, then copy/paste it into a new doc. You’ll see “Paste Options” popup and you can choose to pull in no rows and just table headers. This will set your row ID to 1.
It’s a little bit of a manual process, but if you put everything that’s intertwined with formulas in one section, you highlight everything in that section and paste it in the new doc.
@BenLee I tried this but it relies on everything intertwined being in the same section, which doesn’t work well for us since we have source “admin” tables in a separate folder away from our filtered views, and various sections viewing on the same data.
Would be a nice feature to reset the ID somehow explicitly on tables to support templates, so that our document templates with empty data can all start at 0 or 1.
Yes, it does rely on everything being in that same section, which can be tough.
The RowID() is mostly intended to be a unique identifier and not necessarily a counter, but I find myself wanting to use it that way as well. For now, we don’t have a solution other than other Rank() workarounds, but this still leaves the issue you’re describing.
Just a bump on this, still would be a great feature to have. I find myself re-using project management documents a lot, and the ids are very large for new projects.
Compare it to Jira, where you start a project and everyone can easily use the ID number in pull requests, time trackers, or even to lookup the issue in a URL query.
I guess a hack is to note the initial ID after adding the first row, and then creating a Display ID column that just subtracts that value from the Row ID?
Alison the formula does subtract the number, but the idea behind caching the number off as a saved variable is just to protect against the possibility that the “first” row in the table getting deleted and then changing all the ID values.
@Tetel_G maybe a miscommunication, but the Find function is affected by deleted rows. For example the following table had 4 rows, and then the 3rd row was deleted. Then the Find result changed from 4 to 3. We want ID’s that are not affected by row deletions. It should remain as 4. .
The internal Row ID property that all coda rows have has this property, but the problem in this thread is that those ID’s can become very large and there is no way to reset them if a table is cleared.
.