tpansino
  • Joined on 2020-06-11
tpansino commented on issue vikunja/vikunja#874 2021-06-11 05:14:08 +00:00
User's name missing on GitLab.com OIDC first login

@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?

tpansino commented on issue vikunja/vikunja#864 2021-06-11 05:02:20 +00:00
OpenID: Internal Server Error

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.

tpansino closed issue vikunja/vikunja#864 2021-06-11 05:02:20 +00:00
OpenID: Internal Server Error
tpansino commented on issue vikunja/vikunja#874 2021-05-27 17:45:41 +00:00
User's name missing on GitLab.com OIDC first login

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…

tpansino commented on issue vikunja/vikunja#864 2021-05-26 06:18:24 +00:00
OpenID: Internal Server Error

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…

tpansino opened issue vikunja/vikunja#874 2021-05-26 06:14:21 +00:00
User's name missing on GitLab.com OIDC first login
tpansino commented on issue vikunja/vikunja#864 2021-05-22 00:54:00 +00:00
OpenID: Internal Server Error

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…

tpansino commented on issue vikunja/vikunja#864 2021-05-21 21:23:17 +00:00
OpenID: Internal Server Error

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…
tpansino commented on issue vikunja/vikunja#864 2021-05-20 06:18:55 +00:00
OpenID: Internal Server Error

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:…

tpansino commented on issue vikunja/vikunja#864 2021-05-19 21:17:02 +00:00
OpenID: Internal Server Error

@konrad I'm seeing the /authorize URL coming out of both Authentik and GitLab.com looks like…

tpansino commented on issue vikunja/vikunja#864 2021-05-19 07:34:51 +00:00
OpenID: Internal Server Error

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…

tpansino commented on issue vikunja/vikunja#864 2021-05-19 07:02:36 +00:00
OpenID: Internal Server Error

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…

tpansino commented on issue vikunja/vikunja#864 2021-05-19 06:59:07 +00:00
OpenID: Internal Server Error

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…

tpansino reopened issue vikunja/vikunja#864 2021-05-19 06:42:29 +00:00
OpenID: Internal Server Error
tpansino opened issue vikunja/vikunja#864 2021-05-15 23:08:45 +00:00
OpenID: Internal Server Error
tpansino commented on issue vikunja/frontend#152 2020-06-12 20:09:26 +00:00
500 when get issue

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.

tpansino commented on issue vikunja/frontend#62 2020-06-12 17:18:14 +00:00
500 when get issue

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?

tpansino opened issue vikunja/frontend#155 2020-06-12 17:11:33 +00:00
Feature request: repeating tasks should always repeat in the future
tpansino commented on issue vikunja/frontend#152 2020-06-12 17:09:30 +00:00
500 when get issue

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.

tpansino commented on issue vikunja/frontend#152 2020-06-11 22:51:39 +00:00
500 when get issue

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.