ActivityWatch/aw-server-rust

Persist settings to server

iloveitaly opened this issue · 8 comments

Is there a reason we don't persist categorization preferences on the server side? I can't imagine why this wouldn't be preferred. Would be a great QOL improvement.

Tried to find the tracking issue for this, but couldn't find it.

The plan is:

  • add a KV store to the databases
  • implement appropriate API endpoint
  • make aw-webui always check server settings first, and if not present, initialize with store browser localstore settings (upgrade) or defaults (init).

I found this:

What's left is adding support to aw-server-python (should be easy, just need to get the db migration right, but I just did something similar in ActivityWatch/aw-server#128), then just do the aw-webui part.

I agree it would be a great QOL improvement, I've just personally gotten a bit lazy as it's good enough for me.

I just added a link to this issue from the web UI: ActivityWatch/aw-webui@1f194ff

Contributions welcome!

PetbkA commented

v0.12.3b6 - BTW, current warning about settings storage isn't quite correct:

These settings are only saved in your browser and will not remain if you switch browser

Settings aren't even depend on browser but rather on cookies, 'cause if you clear them for AW site - you'll lost your settings even without switching browser

@PetbkA They are technically stored in localStorage, not cookies.

But yes, if the user clears the site data then it is lost.

I finished this today, see ActivityWatch/aw-webui#493

Might need some battle-testing in beta releases (releasing v0.12.3b11 later today), but seems pretty ready!

Tracking issue was here: ActivityWatch/activitywatch#348

Woohoo! So exciting :)

This issue is still cited in the AW AOSP GUI:

Screenshot_20240107-140452.png

@RokeJulianLockhart The Android app is running an older version of the web UI and server.

Once it gets updated (might be a while), the notice will disappear.