Project

General

Profile

Actions

Feature #6721

open

Allow setting issue assignment by username via REST interface

Added by Ian Epperson over 13 years ago. Updated about 12 years ago.

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

0%

Estimated time:
Resolution:

Description

Background
The REST interface allows setting the assigned_to_id on an issue. However, this requires that the user's ID number is known - currently this is unavailable. Even when this becomes available, discovering the ID would require a second HTTP request.

Proposed Feature
Allow sending the assigned_to_name field through both the POST (create new issue) and PUT (update issue) operations.


Files

feature_6721.diff (4.04 KB) feature_6721.diff Sridhar P, 2012-01-05 09:04
feature_6721_2.diff (9.24 KB) feature_6721_2.diff Sridhar P, 2012-01-05 14:18
feature_6721_3.diff (9.22 KB) feature_6721_3.diff Sridhar P, 2012-01-06 07:04
feature_6721_4.diff (8.72 KB) feature_6721_4.diff Sridhar P, 2012-01-06 14:44

Related issues

Has duplicate Redmine - Feature #8531: Task's "assignee" should be specified by login instead of user IDClosed2011-06-04

Actions
Actions #1

Updated by Toshi MARUYAMA almost 13 years ago

  • Category set to REST API
Actions #2

Updated by Alex Last almost 13 years ago

this feature would be VERY useful for my application. I currently have to use "Admin" user to create tasks, which is a bad solution

Actions #3

Updated by Alex Last about 12 years ago

without this feature, tasks manipulation via REST is quite limited. say, I want to load data from Redmine, edit assignments in some other program (Microsoft Project in my case) and then save back to Redmine. I don't know user database IDs (doh!), but Redmine expects "assigned_to_id" parameter set for issues. This is definitely not user-friendly. The assignment should be possible via user login name.

Actions #4

Updated by Sridhar P about 12 years ago

I have created a patch for this feature against the trunk (at revision 8513). Attached is the diff file.

Actions #5

Updated by Alex Last about 12 years ago

Thank you, Sridhar. I really hope this will be accepted by Redmine guys...

Actions #6

Updated by Sridhar P about 12 years ago

This will work only when the "assigned_to_id" is NOT set and "assigned_to_name" is set. To be more specific, this will work only when params[:issue][:assigned_to_id] is NOT set and params[:issue][:assigned_to_name] is set.

Actions #7

Updated by Etienne Massip about 12 years ago

Alexey Skor wrote:

Thank you, Sridhar. I really hope this will be accepted by Redmine guys...

The problem with this patch is that it only works for issue creation/update.

Maybe there should be a more specific solution; doesn't the project_id parameter accept the project natural key?

Actions #8

Updated by Sridhar P about 12 years ago

Etienne Massip wrote:

The problem with this patch is that it only works for issue creation/update.

Maybe there should be a more specific solution; doesn't the project_id parameter accept the project natural key?

Etienne: What are the other methods that need the assigned_to_name feature? While creating the feature, Ian Epperson wrote that he needed this feature for create and update.

Actions #9

Updated by Etienne Massip about 12 years ago

For consistency this could include GET /users/[username].:format, GET /issues.:format?assigned_to_id=[username], POST/PUT news, etc.

Actions #10

Updated by Sridhar P about 12 years ago

More functions are available with the login name now.
show, edit, update, destroy, edit_membership and destroy_membership of the users controller are available with the login name now.
GET /users/[username]
GET /users/[username]/edit
PUT /users/[username]
DELETE /users/[username]
PUT /users/[username]/memberships/[membership-id]
DELETE /users/[username]/memberships/[membership-id]

NOTE: The functions for the users controller will fail on the edge case where the login-name is composed of digits only.

Issues can now be accessed with the "assigned_to_name" parameter;
GET /issues.:format?assigned_to_name=[username]

News table does not have the assigned_to_id field. It has the author_id which defaults to the currently logged in user.

Attached is the patch.

Actions #11

Updated by Etienne Massip about 12 years ago

I was wondering if the Project model way could be applied: source:/trunk/app/models/project.rb#L253

Actions #12

Updated by Sridhar P about 12 years ago

Etienne Massip wrote:

I was wondering if the Project model way could be applied: source:/trunk/app/models/project.rb#L253

As I understand it, yes, it can be done. That would impact every User.find([id]) call. If that is the preferred way of doing, then I will do it. Can you confirm that it is the preferred way?

Actions #13

Updated by Sridhar P about 12 years ago

Here you go. User.find works the same way that Project.find does; you can get user by User.find([username]) and User.find([id]).
I have used better names for the functions that fetch the id from the login name.

Actions #14

Updated by Etienne Massip about 12 years ago

Sridhar P wrote:

Here you go. User.find works the same way that Project.find does; you can get user by User.find([username]) and User.find([id]).

Yes, I think it's cleaner now since the behavior will be the same everywhere in the app.

I have used better names for the functions that fetch the id from the login name.

Actually you should remove the changes in IssueController and use the assigned_to_id=<username> syntax (for consistency with project_id).

Actions #15

Updated by Sridhar P about 12 years ago

Etienne Massip wrote:

Actually you should remove the changes in IssueController and use the assigned_to_id=<username> syntax (for consistency with project_id).

As far as I know project_id is cannot be updated with the api. So, it is in a different league.

The "assigned_to_id" field can be updated. If we allow the login name to be sent as a value for the "assigned_to_id" key, we'll have to modify the assigned_to_id and set it to the id of the user if we encounter a login name. Is that okay?

Also, this will have same edge case scenario as with the users model. If a user has a login name composed of digits only, then we'll have the same problem (login name will be considered to be an id, because it contains digits only).

Do you still want me to go ahead with the assigned_to_id=[login] syntax?

Actions #16

Updated by Sridhar P about 12 years ago

I tried to do it but it is interfering with other methods:
  • Create issue with group assignment
  • Update issues with group assignment

These methods use the group id for the assigned_to_id field. assigned_to_name seems to be a safe bet.

Actions #17

Updated by Sridhar P about 12 years ago

Looks like I had an unrelated error. I have modified the code to enable the usage of assigned_to_id=[login]. You should be able to use login instead of id.

Actions #18

Updated by Alex Last about 12 years ago

can we just keep "assigned_to_id" for backward compatibility and
add "assigned_to" parameter, which would take either ID or Login name? if "assigned_to" is used, then "assigned_to_id" is ignored (and should be marked as "deprecated" and removed in the future Redmine releases).

using "assigned_to_id" for both "id" and "login" seems like a bad decision to me.

if the login name contains numbers only, then this user is plain stupid and we should ignore or punish him =:-] just kidding. we can disable digits-only login names if we want to reuse the same "ID or String Key (which is a login name in this particular case)" approach in the other parts of the API to make it more consistent.

Actions #19

Updated by Sridhar P about 12 years ago

Given a choice I would stick with assigned_to_name. The intent is clear and it is unambiguous. But then the decision isn't in my hands :)

Actions

Also available in: Atom PDF