[Bug]: getUser endpoint regex is failing? #898

Open
opened 2026-02-04 21:34:55 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @hwelch-fle on GitHub (Jan 19, 2026).

Where is the problem occurring?

I encountered the problem while interacting with the server (Backend)

What browsers are you seeing the problem on?

Other

Current behavior

When calling the getUser endpoint, a 400 error is thrown even when the user requesting the info is admin:

plankapy code directly accessing the endpoint:

>>> try:
...     print(planka.endpoints.getUser('1691478853400134866'))
... except HTTPStatusError as e:
...     print(e.response.json())
{
    'code': 'E_MISSING_OR_INVALID_PARAMS',
    'problems': [
        'Invalid "id":\n  · Value (\'1691478853400134866\') did not match the configured regular expression (/\\/^[1-9][0-9]*$\\/|^me$/)'
    ], 
    'message': 'The server could not fulfill this request (`GET /api/users/1691478853400134866`) due to 1 missing or invalid parameter.'
}

Not totally sure why this is happening since when I test the regex ^[1-9][0-9]*$|^me it correctly captures ids and me.

This is the only endpoint that fails the id regex check that I've seen so far.

Additionally, when accessing me the regex always passes:

>>> try:
...     print(planka.me) # Alias for getUser('me')
... except HTTPStatusError as e:
...     print(e.response.json())
User(schema={...}, ...)

I am also interested in how one would get User info when not logged in as an admin, since the current endpoints seems to only allow admins and board managers to access User info directly. All other users need to get user info by inspecting the included attributes of cards and boards. This is fine, but it also means that lower permission users can't get updated user info without querying cards.

Desired behavior

Explained above

Steps to reproduce

send a GET request to /api/users/{:id} with a userId

Other information

No response

Originally created by @hwelch-fle on GitHub (Jan 19, 2026). ### Where is the problem occurring? I encountered the problem while interacting with the server (Backend) ### What browsers are you seeing the problem on? Other ### Current behavior When calling the `getUser` endpoint, a `400` error is thrown even when the user requesting the info is admin: plankapy code directly accessing the endpoint: ```python >>> try: ... print(planka.endpoints.getUser('1691478853400134866')) ... except HTTPStatusError as e: ... print(e.response.json()) { 'code': 'E_MISSING_OR_INVALID_PARAMS', 'problems': [ 'Invalid "id":\n · Value (\'1691478853400134866\') did not match the configured regular expression (/\\/^[1-9][0-9]*$\\/|^me$/)' ], 'message': 'The server could not fulfill this request (`GET /api/users/1691478853400134866`) due to 1 missing or invalid parameter.' } ``` Not totally sure why this is happening since when I test the regex `^[1-9][0-9]*$|^me` it correctly captures ids and `me`. This is the only endpoint that fails the id regex check that I've seen so far. Additionally, when accessing `me` the regex always passes: ```python >>> try: ... print(planka.me) # Alias for getUser('me') ... except HTTPStatusError as e: ... print(e.response.json()) User(schema={...}, ...) ``` I am also interested in how one would get User info when not logged in as an admin, since the current endpoints seems to only allow admins and board managers to access User info directly. All other users need to get user info by inspecting the `included` attributes of cards and boards. This is fine, but it also means that lower permission users can't get updated user info without querying cards. ### Desired behavior Explained above ### Steps to reproduce send a `GET` request to `/api/users/{:id}` with a userId ### Other information _No response_
Author
Owner

@hwelch-fle commented on GitHub (Jan 19, 2026):

Currently, my solution to get user info on cards is to check bottom up, but having an endpoint that can get even just a user's name attribute from an id would save some load:

Current:

@property
def user(self) -> User:
    """The User who created the Comment"""
    _usrs = [u for u in self.card.board.users if self.schema['userId'] == u.id]
    if _usrs:
        return _usrs.pop()

Better?

@property
def user(self) -> User:
    """The User who created the Comment"""
    return User(self.endpoints.getUserName(self.schema['userId'])['item'], self.session)

Or one that requires passing a board so currentUser Board Membership can be checked:

# /api/boards/{:boardID}/users/{:userId}
@property
def user(self) -> User:
    """The User who created the Comment"""
    return User(self.endpoints.getBoardUser(self.board.id, self.schema['userId'])['item'], self.session)
@hwelch-fle commented on GitHub (Jan 19, 2026): Currently, my solution to get user info on cards is to check bottom up, but having an endpoint that can get even just a user's `name` attribute from an id would save some load: Current: ```python @property def user(self) -> User: """The User who created the Comment""" _usrs = [u for u in self.card.board.users if self.schema['userId'] == u.id] if _usrs: return _usrs.pop() ``` Better? ```python @property def user(self) -> User: """The User who created the Comment""" return User(self.endpoints.getUserName(self.schema['userId'])['item'], self.session) ``` Or one that requires passing a board so `currentUser` Board Membership can be checked: ```python # /api/boards/{:boardID}/users/{:userId} @property def user(self) -> User: """The User who created the Comment""" return User(self.endpoints.getBoardUser(self.board.id, self.schema['userId'])['item'], self.session) ```
Author
Owner

@meltyshev commented on GitHub (Jan 19, 2026):

Hey! Regarding the regex - we fixed that, the wrong regex was specified in validation: https://github.com/plankanban/planka/issues/1302.

If you're actively testing things with plankapy, I suggest using the nightly version (until the final release appears) - a lot of issues should be resolved, and there are new features added, like ability to link tasks to cards and more (should be also described in the Swagger spec, but won't work with just rc.4 version). We're trying to finish everything faster to get a release out already - things, as always, got delayed...

And regarding fetching a user - we did that on purpose, so only admins and project owners can access and fetch any user info, while regular board members only see the available ones. I tried to implement fetching a user by id for a regular role, but it was a bit tricky to calculate all the available ids to prevent unpermitted access. I understand this isn't the best approach in terms of API usage - I'll try to fix that somehow :)

For now, the temporary solution should be fine until we implement proper by-id fetching. The only issue I see with this approach is that comments can reference user ids that are no longer on the board or even deleted (null), but the endpoint for fetching comments should include all users presented.

@meltyshev commented on GitHub (Jan 19, 2026): Hey! Regarding the regex - we fixed that, the wrong regex was specified in validation: https://github.com/plankanban/planka/issues/1302. If you're actively testing things with plankapy, I suggest using the `nightly` version (until the final release appears) - a lot of issues should be resolved, and there are new features added, like ability to link tasks to cards and more (should be also described in the Swagger spec, but won't work with just `rc.4` version). We're trying to finish everything faster to get a release out already - things, as always, got delayed... And regarding fetching a user - we did that on purpose, so only admins and project owners can access and fetch any user info, while regular board members only see the available ones. I tried to implement fetching a user by id for a regular role, but it was a bit tricky to calculate all the available ids to prevent unpermitted access. I understand this isn't the best approach in terms of API usage - I'll try to fix that somehow :) For now, the temporary solution should be fine until we implement proper by-id fetching. The only issue I see with this approach is that comments can reference user ids that are no longer on the board or even deleted (null), but the endpoint for fetching comments should include all users presented.
Author
Owner

@hwelch-fle commented on GitHub (Jan 20, 2026):

Hey! Regarding the regex - we fixed that, the wrong regex was specified in validation: #1302.

If you're actively testing things with plankapy, I suggest using the nightly version (until the final release appears) - a lot of issues should be resolved, and there are new features added, like ability to link tasks to cards and more (should be also described in the Swagger spec, but won't work with just rc.4 version). We're trying to finish everything faster to get a release out already - things, as always, got delayed...

Gotcha! I'm currently running the lastest rc4 release using Docker. So I'll change that.

And regarding fetching a user - we did that on purpose, so only admins and project owners can access and fetch any user info, while regular board members only see the available ones. I tried to implement fetching a user by id for a regular role, but it was a bit tricky to calculate all the available ids to prevent unpermitted access. I understand this isn't the best approach in terms of API usage - I'll try to fix that somehow :)

For now, the temporary solution should be fine until we implement proper by-id fetching. The only issue I see with this approach is that comments can reference user ids that are no longer on the board or even deleted (null), but the endpoint for fetching comments should include all users presented.

Yeah, implementing the interface in plankapy really reveals all the annoying little nuisances that come with permissions. I'm currently letting everything fail pretty hard and just raise the raw HTTPError for testing. There's a couple places where I've implemented checks on current_user by storing me.id and me.role after logon.

The biggest hurdle for me now is deciding how to handle caching. All objects maintain endpoint binds and attribute access currently hits the local cache until sync is called (if a GET endpoint exists). All attribute writes update the local instance cache, and all included hit the provided GET endpoint on access.

I'm okay with this being a bit slow for now since it's primarily meant to automate manual tasks that would take forever anyways.

The interface alone is up to 3000 lines lol. Lot of boilerplate, but also a ton of functionality that lets you manage and traverse a Planka instance using list comprehensions.

@hwelch-fle commented on GitHub (Jan 20, 2026): > Hey! Regarding the regex - we fixed that, the wrong regex was specified in validation: [#1302](https://github.com/plankanban/planka/issues/1302). > > If you're actively testing things with plankapy, I suggest using the `nightly` version (until the final release appears) - a lot of issues should be resolved, and there are new features added, like ability to link tasks to cards and more (should be also described in the Swagger spec, but won't work with just `rc.4` version). We're trying to finish everything faster to get a release out already - things, as always, got delayed... Gotcha! I'm currently running the lastest `rc4` release using Docker. So I'll change that. > And regarding fetching a user - we did that on purpose, so only admins and project owners can access and fetch any user info, while regular board members only see the available ones. I tried to implement fetching a user by id for a regular role, but it was a bit tricky to calculate all the available ids to prevent unpermitted access. I understand this isn't the best approach in terms of API usage - I'll try to fix that somehow :) > > For now, the temporary solution should be fine until we implement proper by-id fetching. The only issue I see with this approach is that comments can reference user ids that are no longer on the board or even deleted (null), but the endpoint for fetching comments should include all users presented. Yeah, implementing the interface in plankapy really reveals all the annoying little nuisances that come with permissions. I'm currently letting everything fail pretty hard and just raise the raw `HTTPError` for testing. There's a couple places where I've implemented checks on `current_user` by storing `me.id` and `me.role` after logon. The biggest hurdle for me now is deciding how to handle caching. All objects maintain endpoint binds and attribute access currently hits the local cache until `sync` is called (if a `GET` endpoint exists). All attribute writes update the local instance cache, and all `included` hit the provided `GET` endpoint on access. I'm okay with this being a bit slow for now since it's primarily meant to automate manual tasks that would take forever anyways. The interface alone is up to 3000 lines lol. Lot of boilerplate, but also a ton of functionality that lets you manage and traverse a Planka instance using list comprehensions.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/planka#898