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

Categorization Rules deleted when chrome browser cookies cleared #420

Closed
8bitgentleman opened this issue Apr 21, 2020 · 10 comments
Closed

Comments

@8bitgentleman
Copy link

For us to be able to understand the issue you're having you need to follow this template. Please make sure there isn't already an issue for the bug you've found, otherwise it'll just take more resources, which means less time for us to actually fix bugs. Thanks for reporting!

Describe the bug

I had to clear chrome's browser cookies the other day which unintentionally deleted all my Categorization Rules as well. I do see that the settings pages says "These settings are only saved in your browser" but I did not realize that meant clearing cookies would delete them.

To Reproduce

Steps to reproduce the behavior:

  1. Set up and save custom Categorization Rules
  2. Delete chrome cookies for the last hour

Expected behavior

Categorization Rules should be persistent, perhaps saved in the server database?

Environment

  • ActivityWatch version: v0.9.2
  • OS: [macOS (Mojave)]
@8bitgentleman 8bitgentleman changed the title Categorization Rules deleted when chrome browser cookies (from the last 24hrs) were cleared Categorization Rules deleted when chrome browser cookies cleared Apr 21, 2020
@ErikBjare
Copy link
Member

We're already working on this, as is said at the top of the settings page.

@8bitgentleman
Copy link
Author

Ok, great I didn't see an issue open with a quick search. Sorry if this was spam

@ErikBjare
Copy link
Member

One of the issues (I think there might be another one as well) is here: #348

Closing.

@ErikBjare
Copy link
Member

The PR that implemented the necessary API in aw-server-rust is here: ActivityWatch/aw-server-rust#87

And congrats to issue #420 :)

@8bitgentleman
Copy link
Author

8bitgentleman commented Apr 21, 2020

And congrats to issue #420 :)

haha funny coincidence

The PR that implemented the necessary API in aw-server-rust is here: ActivityWatch/aw-server-rust#87

Just switching from aw-server to aw-server-rust throws a 404. Is the rust server not ready yet or is there something else I need to do to switch? (I'm on macOS)

@ErikBjare
Copy link
Member

ErikBjare commented Apr 21, 2020

The settings/key-value API is implemented in aw-server-rust, but we're still working on migrating the web UI to actually use it.

If you get a 404 for localhost:5600 with aw-server-rust, that probably means the web UI files haven't been built and placed into the correct resource folder. How do you run aw-server-rust?

@8bitgentleman
Copy link
Author

Thanks for these quick responses!
I have been running Activity Watch with the latest .app and starting it using the window watcher workaround from #380 (I'm on Mojave)

@xylix
Copy link
Contributor

xylix commented Apr 22, 2020

When you switch to aw-server-rust did you first shut down aw-server in the UI? They will both try to use the same port if not closed so that could cause a failure.

@8bitgentleman
Copy link
Author

Yes I did, I unchecked aw-server before I checked aw-server-rust

@johan-bjareholt
Copy link
Member

johan-bjareholt commented Apr 22, 2020

@xylix If it's a 404, maybe we need to add some extra path here for the app bundle?
https://github.com/ActivityWatch/aw-server-rust/blob/642a5315cd7ccbcb5aa24df73ce1b6096881616a/aw-server/src/main.rs#L102

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

No branches or pull requests

4 participants