Skip to content
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

Source timestamp not updating in UI #442

Closed
sssoleileraaa opened this issue Jun 27, 2019 · 9 comments · Fixed by #778
Closed

Source timestamp not updating in UI #442

sssoleileraaa opened this issue Jun 27, 2019 · 9 comments · Fixed by #778
Labels
bug Something isn't working

Comments

@sssoleileraaa
Copy link
Contributor

Description

The timestamp in SourceWidgets are no longer updating in the UI

@eloquence eloquence added this to the 0.2.0alpha milestone Jul 2, 2019
@eloquence eloquence added this to Current Sprint - 8/7-8/21 in SecureDrop Team Board Aug 7, 2019
@eloquence eloquence added the bug Something isn't working label Aug 21, 2019
@eloquence eloquence moved this from Current Sprint - 8/21-9/4 to Near Term Backlog in SecureDrop Team Board Aug 21, 2019
@redshiftzero redshiftzero moved this from Near Term - SD Workstation to Nominated for Next Sprint in SecureDrop Team Board Oct 8, 2019
@eloquence eloquence moved this from Nominated for Next Sprint to Current Sprint - 10/9-10/23 in SecureDrop Team Board Oct 9, 2019
@redshiftzero
Copy link
Contributor

ah looks like this is also true of the LastUpdatedDate in the SourceProfileShortWidget, i.e. the "seconds ago" part here won't update:

Screen Shot 2019-10-17 at 8 24 59 AM (2)

@redshiftzero
Copy link
Contributor

seems like for each one of these situations adding 1. a QTimer and 2. a slot for updating the timestamp is the way to go here

@eloquence eloquence moved this from Current Sprint - 11/6-11/20 to Near Term - SD Workstation in SecureDrop Team Board Nov 20, 2019
@eloquence eloquence modified the milestones: 0.2.0alpha, 0.2.0beta Dec 12, 2019
@sssoleileraaa
Copy link
Contributor Author

I just checked the server-side's last_updated values in the sources table and see that the value is not being updated when a source sends a new message. This would explain why it's not showing up correctly in the client.

@eloquence
Copy link
Member

This has other implications e.g. for journalist notifications, so we've agreed to investigate last_updated behavior in core at a high priority as part of this sprint.

@eloquence eloquence moved this from Near Term - SD Workstation to Current Sprint (1/22-2/5) in SecureDrop Team Board Jan 22, 2020
@ntoll
Copy link
Contributor

ntoll commented Feb 4, 2020

I've just looked into this and observe the same behaviour mentioned by @creviera. As far as I can tell once the server side issue is fixed, "it should just work" ™️

@eloquence
Copy link
Member

I just checked the server-side's last_updated values in the sources table and see that the value is not being updated when a source sends a new message. This would explain why it's not showing up correctly in the client.

I can't reproduce this in develop. What I'm doing is:

  1. Spin up a development environment with make dev on latest master
  2. Create a new source via the source UI
  3. Submit a series of messages/documents as the source, and verify the last_updated timestamp in the Docker dev container (including with logout/login cycles)

Here's what I'm seeing as I'm sending new messages/documents:

sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';
ecstatic countrywoman|2020-02-04 20:01:43.698790
sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';
ecstatic countrywoman|2020-02-04 20:01:49.435621
sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';
ecstatic countrywoman|2020-02-04 20:01:58.341733
sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';
ecstatic countrywoman|2020-02-04 20:02:03.356957
sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';
ecstatic countrywoman|2020-02-04 20:02:10.194386
sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';
ecstatic countrywoman|2020-02-04 20:02:22.511501
sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';
ecstatic countrywoman|2020-02-04 20:02:32.010802
sqlite> select journalist_designation,last_updated from sources where journalist_designation='ecstatic countrywoman';

The timestamp is not updated when a journalist sends a reply, but I believe that's the expected behavior as it's currently tracking last activity by the source.

@sssoleileraaa
Copy link
Contributor Author

it sounds like this is a misunderstanding of what "last activity" meant. i was expecting to see the "last activity" timestamp update when new replies were accepted by the server.

@eloquence
Copy link
Member

@creviera Does the timestamp update as expected when there is activity by the source?

@ntoll
Copy link
Contributor

ntoll commented Feb 6, 2020

It appears not:

last_update

Note how the timestamp on the source widget is updated, whereas the timestamp above the conversation isn't working.

However, if I restart the app, then the correct date is shown above the conversation. The problem appears to be the timestamp update doesn't happen when a new message is received from the server. I'll investigate and create a fix now.

ntoll added a commit to ntoll/securedrop-client that referenced this issue Feb 6, 2020
@sssoleileraaa sssoleileraaa moved this from Current Sprint (2/5-2/20) to In Development in SecureDrop Team Board Feb 6, 2020
SecureDrop Team Board automation moved this from In Development to Done Feb 6, 2020
sssoleileraaa pushed a commit that referenced this issue Feb 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

4 participants