Project Area Rename creates problems with API-based tools

I have read numerous posts and defects regarding the problems encountered after a Project Area is renamed.

The root of the problems is that when a Project Area is renamed the Project Alias (an internal ID for the project) is not. The Project Area Alias = Project Area Name when the project is first created.

The problems encountered are when a user wishes to reference the Project Area from the URL Utility, Copy Utility, Command Line Adaptor and anything that uses the REST API. This is manifest in an Error 400 or some other "project does not exist" type of error.

The user (through post and defect replies) is asked to simply refer to the Project Alias. This of course works. But lets look beyond this workaround.

We should still be able to interact with Project Areas using the "new" name. Forcing the use of the Project Alias is like asking those that refer to Resources to only use the URI. When, of course, we can interact with Resources using both a URI and an "external ID".

I therefore ask if there is:

a. An intention to change the behaviour such that, when we use REST-based tools, we can refer to the Project Area name (renamed or otherwise) AND/OR;

b. Is there / will there be an ability to change the Project Area Alias OR at the very least store the Project Area Alias as a numeric UID (much the same as the Resources).

Many thanks, Simon

Hi Simon,
Just one more thing: a better way to get Project data (including aliases) is to use the Project feed:
https://<server>/jazz/secure/service/com.ibm.rqm.integration.service.IIntegrationService/projects

There was a reason why alias was used instead of project area but to be honest I do not remember the details of why. I'd recommend submitting a workitem on jazz.net if you're interested.

Regards,
John Nason

I have read numerous posts and defects regarding the problems encountered after a Project Area is renamed.

The root of the problems is that when a Project Area is renamed the Project Alias (an internal ID for the project) is not. The Project Area Alias = Project Area Name when the project is first created.

The problems encountered are when a user wishes to reference the Project Area from the URL Utility, Copy Utility, Command Line Adaptor and anything that uses the REST API. This is manifest in an Error 400 or some other "project does not exist" type of error.

The user (through post and defect replies) is asked to simply refer to the Project Alias. This of course works. But lets look beyond this workaround.

We should still be able to interact with Project Areas using the "new" name. Forcing the use of the Project Alias is like asking those that refer to Resources to only use the URI. When, of course, we can interact with Resources using both a URI and an "external ID".

I therefore ask if there is:

a. An intention to change the behaviour such that, when we use REST-based tools, we can refer to the Project Area name (renamed or otherwise) AND/OR;

b. Is there / will there be an ability to change the Project Area Alias OR at the very least store the Project Area Alias as a numeric UID (much the same as the Resources).

Many thanks, Simon