Feature #6721
open
Allow setting issue assignment by username via REST interface
0%
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
Related issues
Updated by Toshi MARUYAMA
Updated by Alex Last over 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
Updated by Alex Last almost 13 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.
Updated by Sridhar P almost 13 years ago
- File feature_6721.diff feature_6721.diff added
I have created a patch for this feature against the trunk (at revision 8513). Attached is the diff file.
Updated by Alex Last almost 13 years ago
Thank you, Sridhar. I really hope this will be accepted by Redmine guys...
Updated by Sridhar P almost 13 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.
Updated by Etienne Massip almost 13 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?
Updated by Sridhar P almost 13 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_idparameter 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.
Updated by Etienne Massip almost 13 years ago
For consistency this could include GET /users/[username].:format, GET /issues.:format?assigned_to_id=[username], POST/PUT news, etc.
Updated by Sridhar P almost 13 years ago
- File feature_6721_2.diff feature_6721_2.diff added
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.
Updated by Etienne Massip almost 13 years ago
I was wondering if the Project model way could be applied: source:/trunk/app/models/project.rb#L253
Updated by Sridhar P almost 13 years ago
Etienne Massip wrote:
I was wondering if the
Projectmodel 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?
Updated by Sridhar P almost 13 years ago
- File feature_6721_3.diff feature_6721_3.diff added
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.
Updated by Etienne Massip almost 13 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).
Updated by Sridhar P almost 13 years ago
Etienne Massip wrote:
Actually you should remove the changes in
IssueControllerand use theassigned_to_id=<username>syntax (for consistency withproject_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?
Updated by Sridhar P almost 13 years ago
- 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.
Updated by Sridhar P almost 13 years ago
- File feature_6721_4.diff feature_6721_4.diff added
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.
Updated by Alex Last almost 13 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.
Updated by Sridhar P almost 13 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 :)