Project

General

Profile

Actions
Copy link

Feature #35839

open

API: Unable to distinguish between user and group, for the assigned_to field

Added by Aed Art over 3 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
REST API
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

The `assigned_to` field for the `issues` resource, and the `default_assignee` for the `projects` resource return either a reference to an existing user or a group.
Yet, it's not possible to distinguish whether it is one or the other - at least not an easy one via the API.

Developers might have to perform additional requests to be API, in hopes of being able to determine if it's user reference or a group. This might not be as easy as it sounds. You only have the name to match against, which depending on display setting, a user's name will be outputted differently in the reference, making it a bit frustrating attempting to compare against.
Furthermore, there is always a change that a group shares the same id as a user (do not have enough understanding of the database schema)?

Possible Solution

Add a new property to the `assigned_to` and `default_assignee` references, indicating exactly it's type.
E.g:

{
  "assigned_to": {
    "id": 1234,
    "name": "Development Group",
    "type": 'group',
  }
}

{
  "default_assignee": {
    "id": 1234,
    "name": "James T. Brandon Jr.",
    "type": 'user',
  }
}
Actions
Copy link
 #1

Updated by Mischa The Evil over 3 years ago

  • Category changed from Plugin API to REST API

Just two notes:

Aed Art wrote:

[...]
You only have the name to match against, [...]

AFAIK you'll also get its id.

Furthermore, there is always a change that a group shares the same id as a user [...]

I don't think that can happen.

Nevertheless, I agree that there should be a way for an API-user to determine what kind of Principal they are given.

Actions
Copy link
 #2

Updated by Holger Just over 3 years ago

  • Tracker changed from Defect to Feature

Furthermore, there is always a change that a group shares the same id as a user (do not have enough understanding of the database schema)?

Users and groups are both stored in the same database table users. Thus each principal (user or group) has a unique ID by definition.

Mischa The Evil wrote:

Nevertheless, I agree that there should be a way for an API-user to determine what kind of Principal they are given.

I agree. For the author and assignees, we should distinguish three cases:

  • regular user
  • anonymous user
  • group

Adding it to the API responses of most objects which have user references (e.g. issues, watchers, wiki pages, news, boards, ...) would probably be a good idea to make it easier to get additional information about the references user (e.g. to decide whether to use /users/ID.json or /groups/ID.json).

Maybe we could just add a hard-coded Principal#api_type (or similar) method for the various Principal sub-classes and use this method in the API views the same way we currently use principal#name there.

Actions
Copy link

Also available in: Atom PDF