A new "Sort Date" Relation that (if not empty) overpowers the Creation Date in the sort function


Surely we all know the problem: sometimes it would become handy (or there is even urgent need) to change the Creation Date of an Object.
There was FRs and some moanings from the users, that this isn’t possible (for some technical reasons, as far as I understand).
But I have an idea!


My idea:

  1. Please implement a new “Sorting Date” Relation that is automatically available for each Objekt.
    Normally there is no need for the user to pay attention or to enter a date in it. It can stay empty in most cases.
    BUT if we sort a Set or Collection by Creation Date and some items in the list should be in another order, then we can enter our desired “Sorting Date” into that new relation.

  2. The sorting function from Set & Collection works as before, BUT if the “Sorting Date” is not empty, it will use this instead of the normal Creation Date.

Minimal effort for the team, but a huge benefit for the users! :heart_eyes:


One example is a daily journal. We don’t have each day the time for holding our diary up to date. Sometimes we write our things some days later. But then the Creation Date doesn’t fit to the event’s Date.
The problem becomes massive if we want to integrate a large amount of old notes from paper or from an other App into Anytype.

I’m also confronted with this problem by writing things like invoices.
I already have some other Date Relations in them, but I often sort by Creation Date, because it fits best most of the time.
Unfortunately, there are always these special cases, where it fits not so good for all items in the list. They appear somewhere in the list but not there where I would expect them.


Of course, the user could manually add a selfmade Relation “Sorting Date” and never use the creation Date again.
But this way would force him to add this “Sorting Date” to each single Page and Note and whatever Object, AND to put a date in them all (a date that’s in most cases identical to the Creation Date). If he left some items out, the sorting will not work as expected.

  • It’s not realistic to enter such a date manually in all of these hundreds or thousands Pages we already have.

Mostly it is the best way to sort for the normal creation Date.
But there are always some (or many) items which dance out of the line.
We need a way to change the order of “creation” manually in such cases.

My idea would solve this problem for the users in the best way and I think it’s also easy to implement.


Simple and highly effective. I agree with your idea, but I think “Custom date” would be a more appropriate label.


If editing the objects’ proper creation or modify dates is facing technical difficulties, a dedicated “Sort date” would IMHO make a lot of sense.

As I understand it, I guess you suggest to create a third default relation next to the regular create and modify dates, which defaults to “today” when the object gets created or modified, but can be changed by the user to any other date.

So sorting by this new date field would have the same effect as sorting by modified-date, with the added value that it can be adjusted.

1 Like

Yes you understand it right.
I explained a slightly different way, but the way you present it would work the same way and even have a small advantage over my original request.

Conclusion: it should be implemented exactly as you explain it! :+1:

However, there is a small difference to your explanation: When modifying the object, the “Sort Date” should not be changed automatically!
Instead, it is automatically set to “Today” when the object is created and from then on this date can only be changed manually.

So implemented, the benefit of your suggestion has the advantage over my original FR, that the user can sort for the normal creation date or for the “sorting date”.
He has the choice!
In my original FR he wouldn’t have this choice.

So, you suggestion is better than my original FR if implemented the way I described here in the edit.

Yes, @Code-Jack, you are right: the system should not automatically update the sort-date when the object gets modified. Otherwise the original value of the sort-date gets lost and that is exactly what your suggestion should prevent :slight_smile: Thank you for thinking it over.

And the task for the programmer is this:
If he implements this feature, so that each Object has this new date relation, then it would normally be empty for the already existing Objects.
This shouldn’t be!
Otherwise, each user would have to manually assign the correct “Sorting Date” to hundreds or thousands of objects. That would have no benefit!

This means that once the new feature has been introduced, the app must automatically do this for each Object:

If “Sorting Date” is empty then
Copy Creation Date into it.
End if

1 Like

@Filip, would you mind merging this FR with the already acknowledged FR for editable modified dates?

I believe the solution suggested by @Code-Jack here is intended and very helpful as a good approximation to the need behind the FR for editable dates.

I don’t like the idea to merge the threads!
My approach differs from the other one. Also it enables further possibilities.

The original Creation Date should stay as it it. I’m against to make it editable.
So it would be paradox if this thread would be merged with one which begs for something I don’t want.

(Off topic)

And anyway:
I generally find it annoying when threads are closed (as is was often the case today!) and/or merged!

A merged thread is rather confusing to read.
It also makes it difficult to find familiar threads again.
It is also unclear what happens to the votes?

In my opinion, a better approach would be to simply place a link in thread A that leads to a similar thread B (and vice versa).
That way, every reader knows that there are different threads and also that there are different approaches to solving the problem.

@Filip closed many threads today.
Including some well-frequented ones with fresh contributions to the discussion.
Also including one in which I wanted to ask one further question. Now I can’t. :frowning:

I totally see you, @Code-Jack. As long as editing the modified date is technically impossible, though, I believe that the manual sort date suggested here would be a viable if not better solution.

So, seen from this perspective, merging the threads makes sense in order to keep the number of feature requests low.

As additional benefit, if merged, this FR gets a lot more votes, and a greater chance to be implemented IMHO.

1 Like

Even if technically possible I’m against it.
The Creation Date is the point in time where someone created something in Anytype.
The Sorting Date is another thing. It’s often identical with the Creation Date, but not allways.

In most case is the Sorting Date the thing the user wants.
Because he was ill for a week and after that he keeps his diary where he wants to add the last days.
In such a case, when he wants to read his dairy one year later or so, in the chronological order, he needs the Sorting Date. Not the Creation Date, because it differs from the events in the diary.

BUT in some cases he needs the real Creation Date.
For example, he would like to trace back which day he did what in Anytype.
He would then be very confused if the Creation Date had been edited.

He may know with certainty that he MUST have created a note on a very specific day.
He doesn’t know enough about the content, which is why the search function doesn’t help him. But he knows that he made an important note on the day of an exhibition (about a person whose name he has forgotten).
However, if the creation date has been edited for some reason (perhaps even accidentally), then this last and only reference is lost.

The examples may seem contrived.
But I have actually experienced real cases like this in the past.

It is roughly comparable to the weakness of the Windows file system.
Unfortunately, the name of a file is also the identifier.
This means that a deep link to a specific file on the hard disc no longer works if the file has been renamed.
This is better solved in Anytype!
You can rename Objects at any time without the links going nowhere.
Because the Object’s name is not identically with it’s identifier.

A Creation Date is a Creation Date!
And a Sorting Date is a Sorting Date (although often identical with the CD).
These are two different things.
And one of them is not supposed to be editable!


I don’t believe that.
I more believe, that the programmers become confused from a merged thread and implement one of the different ideas, but not the best one, because of overseeing the differences.
It’s surely better when they see the different approaches and choose the best of them.

And there is one more point, which is perhaps controversial:
When used in a business environment, it is often important that certain data cannot be edited retrospectively.
I don’t know how it is in English-speaking countries, but in Germany the tax office is very strict about such things.

The mere technical possibility of being able to change certain data retrospectively could cause you major problems with the tax office.

It is still too early for this, but I will soon make a FR, begging for a feature that a created invoice CAN NOT longer be modified after printing!
Because this is what the tax office demands.

I want to replace my Lexware Faktura & Auftrag with Anytype.
It’s still a bit too early for that, but I want to do it at some point.
If the time is right for it, I will need such a feature for locking specific documents against further modifications.
The point in time when the locking function was activated by the user, must also be documented (and no chance for the user to change this date!).

No worries. I have an opinion here, but no hot blood.

I’m sure the Anytype team hear everyone who contributes here, and take the best decision based on their strategy and everybody’s input.

1 Like

And I agree that, as you said, the „sort date“ approach we’re suggesting here is better than compromising the technical „last modified“ or „created“ dates, and it delivers at least the same value (e.g. the ability to backdate missed diary entries). Thank you for pointing this out.

Can you give me examples of some of these threads that were closed?

It’s already really hard to navigate all the thousands of FRs we have. Similar requests should be merged so that the devs can easily read through all the feedback related to the feature.

Yes, I can.
Yesterday you closed about 10 threads. :frowning:
Here is one example for a thread in which I wanted to ask a further question, but now it’s impossible:

And here an example for a closed thread with lively discussion and fresh contributions:


And now about merging:

I can only speak for myself, but I find it much more confusing when a huge thread with dozens of posts is created by merging and the connections are lost.

It’s hard for me to imagine that it should somehow be easier for the developers to get through this.
After all, merging does not change the total number of postings.
It becomes more of a confusing wasteland of text that you can only scroll through, but can no longer really grasp the content because too many different solutions have simply been packed together.

I would suggest to rather link the threads to each other, so that a reader (or a developer) can also look into the comparable threads if needed.

There will be more threads then without merging, yes. But they will be clearer and shorter.
As already mentioned, the number of posts will remain the same anyway.

Disclaimer: It’s not my business how the mods here manage this forum.
It’s only a feedback from my side.
I can see no real benefit in closing threads or in merging them. But I see disturbing disadvantages for the users and for the developers.
I strongly believe that linking threads to each other is the better way.

1 Like

My bad about that. I was planning on closing all solved topic from the Any Help category because there was no way to to search for both open and unsolved topics (but we later found a way). I’ll try and see what I can do to reopen some of them.

For merging, I’ll discuss it with the mod team.

1 Like

@Code-Jack if I can reply here, about the comment in:

Maybe I didn’t explain well, but having a (“Sort Date” OR “Creation Date”) Search/Set, it would allow what this FR wants to do.

What it means is: Sort by “Sort Date”. If that relation does not exist or is blank, then use the relation “Creation Date” as the sorting date. The “Sort Date” will always take preference over “Creation Date”, and “Creation Date” will only take effect if “Sort Date” does not exist on the object.

This makes the same sort as adding a “Sort Date” to every object, and initializing it with “Creation Date”.

Yes this was my initial thought as I made this FR.
This is one of two ways to get to Rome.

Later I preferred the other way to Rome: to have the Relation “Sort Date” in each Object.
There are already a lot of (more or less) “hidden” Relations in each Object. One more wouldn’t hurt.

The benefit of this way would be, that we can sort for the new Sorting Date, but also for the Creation Date!
See my posting Nr. 11 for the details why this is to differentiate and why this can be useful.