Currently, it is possible to change a custom field's context and remove a specific project, while the custom field is configured in request types in that project. When done, there is no warning or error that indicates the consequences of that change which are:

• Creating the request from the customer portal will return a 500 ERROR and 'Null' in the response.
• Creating the request from the rest API will return a 500 ERROR with no explanation about the reason for failure.
• There is no obvious error logged in the application or Catalina logs in these cases.

Attaching HAR files and browser console logs for reproducing from GUI.

Browser Console log.log

REST API response below:

curl -D- -u username:password -X POST --data '{"serviceDeskId": "1","requestTypeId": "1","requestFieldValues": {"summary": "Request JSD help via REST - removing field","description": "I need a new mouse for my Mac","customfield_10200":"2017-08-16T14:21:00.000-0500"}}' -H "Content-Type: application/json" http://localhost:8080/rest/servicedeskapi/request -v
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
* Server auth using Basic with user 'maria'
> POST /rest/servicedeskapi/request HTTP/1.1
> Host: localhost:8080
> Authorization: Basic bWFyaWE6bWFyaWE=
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 221
>
* upload completely sent off: 221 out of 221 bytes
< HTTP/1.1 500
HTTP/1.1 500
< X-AREQUESTID: 929x961x1
X-AREQUESTID: 929x961x1
< Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: strict-origin-when-cross-origin
< X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
Content-Security-Policy: frame-ancestors 'self'
< Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
< Set-Cookie: JSESSIONID=9CCB5304D9A0464E764CF384DAFF2053; Path=/; HttpOnly
Set-Cookie: JSESSIONID=9CCB5304D9A0464E764CF384DAFF2053; Path=/; HttpOnly
< X-Seraph-LoginReason: OK
X-Seraph-LoginReason: OK
< Set-Cookie: atlassian.xsrf.token=BMZB-KO3X-TZX9-9HY8_1e10301114b901011e14225009c30a596483c447_lin; Path=/
Set-Cookie: atlassian.xsrf.token=BMZB-KO3X-TZX9-9HY8_1e10301114b901011e14225009c30a596483c447_lin; Path=/
< X-ASESSIONID: v2923x
X-ASESSIONID: v2923x
< X-AUSERNAME: maria
X-AUSERNAME: maria
< Cache-Control: no-cache, no-store, no-transform
Cache-Control: no-cache, no-store, no-transform
< Content-Type: application/json;charset=UTF-8
Content-Type: application/json;charset=UTF-8
< Content-Length: 4
Content-Length: 4
< Date: Tue, 23 Nov 2021 15:29:54 GMT
Date: Tue, 23 Nov 2021 15:29:54 GMT
< Connection: close
Connection: close

<
* Closing connection 0

This can be confusing and results in extra efforts to investigate the reason behind the failure, which is basically caused by the project being removed from the context of one of the custom fields used in that request type. There is room for improvement in this context and here are some suggestions:

1. Improve the error handling so that the API returns a description of the error instead of a null/blank response.
2. Improve the user experience when adding a custom field to a project to make it more obvious which projects the field is being added to or removed from. The list only displays 5 projects while there could be a hundred projects used for that field. The way the UI currently works makes it very easy to make a mistake.
3. Add a warning when removing a custom field from a project if that custom field is still configured on request types.
4. If a custom field is no longer present in a project, add a warning on the screen when editing the request type's fields to indicate that the field is not present in the project.

Note

This is not reproducible with all the custom fields' types. The behaviour was visible when using a DateTimePicker custom field but not with a simple text field.

Steps to reproduce:

1. Add a new custom field of type DateTimePicker to a Service Desk project.
2. Add that field to an issue type.
3. Create a new request type using the issue type, and add the new custom field to the request type.
4. Try to create a new request using your browser. This should work.
5. Remove the custom field from the project.
6. Try to create a new request using your browser. Using Developer Tools in Chrome you'll see that one of the resources loaded returns a status 500 response and the HTTP request will return Null with 500 error.
7. You can also try to create the request using the ServiceDesk API, and it too will return a status 500 response.