@konrad what would you like to do with this bug? It seems minor, and the logs don't seem to yield much insight.
I'm inclined to close and drop it, unless you want to pursue it further?
Apologies for the delay 🙏
I cannot reproduce the Unmarshal
error anymore, so I think it's resolved! Thanks very much for your efforts, marking this one closed.
I honestly can't tell, in fact I can't even reproduce the error message anymore. 😕 The bug is still present though.
Here's the full log with all three log levels set to DEBUG
, starting from…
Yeah, that was with GitLab. I filed a separate issue for it, as you can see. 🙂
I'm not blocked on this issue anymore, but still happy to help debug this further if you'd like assistance. In…
but the error is really weired.
Found it.
Once you said this, I figured it couldn't be related to the OpenID code anymore. So I did a search for Unmarshal
, and I'm pretty certain it's [this…
Ok, I've given up on getting Authentik working, the whole getting started experience felt half-baked and not well documented. Back to getting Gitlab working.
I have:
- Pulled the…
Latest always represents the build from the main branch.
I'm pulling latest
of both the api
and frontend
containers. Still seeing scope=openid
, and `openid/HandleCallback ... json:…
@konrad I'm seeing the /authorize
URL coming out of both Authentik and GitLab.com looks like…
Yes, I'm doing that. But I need an email address to associate with the newly created account. Subsequent authentications with the same (sub, iss) tuple will check if the email address changed and…
Oh I supppose I should mention, I did retry with GitLab, but it also took me a few days to respond because I set up a completely different identity provider (Authentik) to do a second test. That one…
Still doesn't seem to be working, unfortunately, but I think I know the cause now.
The initial request to /authorize
specifies scope=openid
, but based on the [OIDC…
I really like you’re submitting the feature requests as user stories! That’s something not many PMs I work with are capable of...
Thanks, I'm just a lowly DevOps/Backend engineer with past scars from lack of clear communication :)
I think to support both cases we’d need an extra flag
+1 this as a backend dev. I imagine this will take an API change too, but a new flag (or an enum?) is the right way to model the data IMO.
I’d like to make the other one (#155) the default one
Do you mean "I'd like the story in 155 to be the default behavior for repeating tasks" or "I'd like to close out this 152 ticket in favor of 155"? I'm assuming the first.
The main reason the JWT expires is that the user leaves the app or tab to do something else, no? So if it's possible with the workers or some other browser hook, on resume of the app/tab session, do a quick check to see if the JWT is valid, and redirect to login if not.
I'm not a front-end engineer, but that should generally prevent the user from having a chance to enter in data in a form that might be lost, no?
So I'm hearing a second user story, which is:
"As a user, when I mark a repeating task as completed, I want the new due date to always be some date in the future (calculated by adding repeat intervals until the new date is > now), so that tasks like paying bills which are tied to a specific date update properly."
This is great, but not what I want this ticket to focus on. This second story has a workaround - you can just tap Done until the due date is in the future, which for something like a bill usually isn't more than an extra tap or two.
The original story doesn't have a similar workaround, you'd have to update the due date yourself to be 2 weeks from today, which requires doing date math in your head, often across months (vomits), hence my request.
I'll file the second story as another ticket, and if the devs want to combine the two that's fine.
I prefer the idea of repeating task ‘generators’. Where a generator creates a single instance of a task on a repeating basis.
I'm a bit confused - isn't this how Todoist does it?
ended up deleting the repeating task instead an instance I wanted to skip.
Whenever I've wanted to skip a recurring task of this kind in Todoist I just check it off, which marks the existing task instance complete and creates a duplicate instance with the due date set to the current date + the repeat period.
The only downside I've seen to this strategy is that it interferes with Todoist's productivity score, but Vikunja doesn't currently have that.
Could also create a "Skip" button option, in addition to "Mark completed", to enable what you're describing.