New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data view sorts by creation time, not post time #2329

Open
tuxpiper opened this Issue Nov 30, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@tuxpiper
Member

tuxpiper commented Nov 30, 2017

This is not buggy or deviant behaviour per-se , just checking with @justinscherer and @jshorland if this change in behaviour is intentional .

It does have some side effects in specific cases though (see Steps to reproduce below)

Expected behaviour

When opening the timeline view, the posts used to be by default sorted by post time , in descending order.

It may be expected that this behaviour to be preserved in the new release.

Actual behaviour

The data view is now sorting posts by creation time by default.

Steps to reproduce the behaviour/error

In most cases post time equals creation time. However, not always.

The difference between creation date and post date is specially visible in deployments containing imported data. An example of this is https://mappingmediafreedom.ushahidi.io

Where
@tuxpiper

This comment has been minimized.

Show comment
Hide comment
@tuxpiper

tuxpiper Nov 30, 2017

Member

Flagging with "Client Request", since most probably the client paying for Mapping Media Freedom will ask what's going on with that sorting.

Member

tuxpiper commented Nov 30, 2017

Flagging with "Client Request", since most probably the client paying for Mapping Media Freedom will ask what's going on with that sorting.

@Celestine22

This comment has been minimized.

Show comment
Hide comment
@Celestine22

Celestine22 Dec 1, 2017

@tuxpiper thanks for flagging this, are you writing a script to update this sorting.

Celestine22 commented Dec 1, 2017

@tuxpiper thanks for flagging this, are you writing a script to update this sorting.

@tuxpiper

This comment has been minimized.

Show comment
Hide comment
@tuxpiper

tuxpiper Dec 1, 2017

Member

@Celestine22 yes, I can update the timestamps in the database, but I'm not doing it yet. Waiting for @justinscherer and @jshorland to acknowledge they have seen this issue.

Member

tuxpiper commented Dec 1, 2017

@Celestine22 yes, I can update the timestamps in the database, but I'm not doing it yet. Waiting for @justinscherer and @jshorland to acknowledge they have seen this issue.

@Celestine22

This comment has been minimized.

Show comment
Hide comment
@Celestine22

Celestine22 Dec 1, 2017

okay! Assigned them just to get an ack!

Celestine22 commented Dec 1, 2017

okay! Assigned them just to get an ack!

@jshorland

This comment has been minimized.

Show comment
Hide comment
@jshorland

jshorland Dec 1, 2017

jshorland commented Dec 1, 2017

@rjmackay

This comment has been minimized.

Show comment
Hide comment
@rjmackay

rjmackay Dec 3, 2017

Member

@jshorland somewhere during the Uchaguzi/data view build - probably when moving the sorting options in the filters dropdown - the default sort field has been changed from post_date to created date. I think it should change back to post_date. We will however have to double check that doesn't effect the behaviour of the 'X new posts' bar...

Member

rjmackay commented Dec 3, 2017

@jshorland somewhere during the Uchaguzi/data view build - probably when moving the sorting options in the filters dropdown - the default sort field has been changed from post_date to created date. I think it should change back to post_date. We will however have to double check that doesn't effect the behaviour of the 'X new posts' bar...

@jshorland

This comment has been minimized.

Show comment
Hide comment
@jshorland

jshorland Dec 4, 2017

ahhh this makes sense now. I believe the reason it was changed was the new "new post" alert. We have to do it by CREATION instead of POST because people need to be alerted of new messages as soon as they come in, not as soon as they are turned into a post

jshorland commented Dec 4, 2017

ahhh this makes sense now. I believe the reason it was changed was the new "new post" alert. We have to do it by CREATION instead of POST because people need to be alerted of new messages as soon as they come in, not as soon as they are turned into a post

@tuxpiper

This comment has been minimized.

Show comment
Hide comment
@tuxpiper

tuxpiper Dec 4, 2017

Member

I was sure there was a good reason for it :)

This may only be relevant to scenarios where we are bulk importing old data, and as such I think it should be contemplated what "post creation time" means in that context.

Member

tuxpiper commented Dec 4, 2017

I was sure there was a good reason for it :)

This may only be relevant to scenarios where we are bulk importing old data, and as such I think it should be contemplated what "post creation time" means in that context.

@justinscherer

This comment has been minimized.

Show comment
Hide comment
@justinscherer

justinscherer Dec 4, 2017

ahhh this makes sense now. I believe the reason it was changed was the new "new post" alert. We have to do it by CREATION instead of POST because people need to be alerted of new messages as soon as they come in, not as soon as they are turned into a post

+1

justinscherer commented Dec 4, 2017

ahhh this makes sense now. I believe the reason it was changed was the new "new post" alert. We have to do it by CREATION instead of POST because people need to be alerted of new messages as soon as they come in, not as soon as they are turned into a post

+1

@rjmackay

This comment has been minimized.

Show comment
Hide comment
@rjmackay

rjmackay Dec 4, 2017

Member

I think its probably correct that the created timestamp is used to get things in the right order when new posts come in.

However just for clarity: Post_date has nothing to do with when a message is turned in to a post. Rather it defaults to same as the created time. The only instances where post_date is different is when someone edits it manually.

Member

rjmackay commented Dec 4, 2017

I think its probably correct that the created timestamp is used to get things in the right order when new posts come in.

However just for clarity: Post_date has nothing to do with when a message is turned in to a post. Rather it defaults to same as the created time. The only instances where post_date is different is when someone edits it manually.

@jrtricafort jrtricafort assigned jrtricafort and unassigned jshorland Apr 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment