request flow

[bikubi]

it's a lot!

companion: okfde/fragdenstaat_de#920

[krmax44]

Seems like migrations are missing.

[krmax44]

This seems kind of brittle. Maybe instead, we could store the user id in the session storage data, and only use it if it matches the current one.

Can you think of problematic situations of PII data surviving a logout?

[bikubi]

Logged out users don't have a userId that could be stored; generating a temp uuid just moves the problem elsewhere...
I've had the idea at some point (I though I had left a comment somwhere) to add a userId to the scope ~ sessionStorage.setItem('froide-store-make-request' + user.id, JSON.stringify(….

Problematic situation I just came up with: when you log out in a different tab, the "session tab" remembers your name... hm.

But sessionStorage sounds so clean..!

[krmax44]

But does that lead to glitches or something like that? Regarding PII, that data doesn't leave the browser unless the user wants to, right? I don't see an inherent privacy issue.

[bikubi]

I don't see glitches; the situation I described above could be described as surprising.

In terms of privacy, I was thinking about the classic "leave a tab open on a public/shared computer".

[krmax44]

@stefanw is there a reason against that?

[krmax44]

Low prio: Altough it's not terribly brittle (however, the sent page is actually always accessible), this should probably be handled by the form. Alternatives:

1. Purge the storage before submitting the form (catching preventDefault). Should the form not properly submit (i.e. offline), all data is lost. Not ideal.
2. Serialize the form data (new FormData(formEl)) and send it via fetch. If it succeeds, purge the storage and redirect.
3. Create a proper API endpoint haha

[bikubi]

Yeah, 2. is what I did with post-upload at the beginning, too.
Not sure how well it will handle the potential proof upload.

[krmax44]

The find similar requests step might currently be a bit confusing, as there's no description of what the user should do. The input field has no placeholder.

Instead of "Continue" (Weiter), maybe the button should say "Skip". Maybe after some time, a little encouragement should pop up ("The information you're looking for isn't available yet? Then let's request it!"), to avoid users getting stuck here.

Low prio/think about it later: Not sure if the "Campaign" filter is that useful here, actually.

[bikubi]

The find similar requests step might currently be a bit confusing, as there's no description of what the user should do. The input field has no placeholder.

Instead of "Continue" (Weiter), maybe the button should say "Skip". Maybe after some time, a little encouragement should pop up ("The information you're looking for isn't available yet? Then let's request it!"), to avoid users getting stuck here.

Changed "next" to "skip".

• if popup, where, how? tooltip for the "skip" button?
• or after the first search, the lower skip button changes back to "next" and gains a help text "The info... let's request it!")
• or maybe, just an (over)emphasized "(optional)" in the heading: "Find similar requests (optional)"?

Low prio/think about it later: Not sure if the "Campaign" filter is that useful here, actually.

yeah, if taken at strict filter face value... but it also sneakily serves as a neat "look at all our campaigns" browser?