If you implement this ticket, you will make Rob very happy!
Problem Description
It's a pain to pull from the log, replace \" and \n, then format. And it is a common task, either for myself or (to a lesser extent) Rob.
Expected Behavior/Solution:
Let's just provide a way to return it via new or existing endpoint. No need to actually perform the search.
If we end up doing this through the search endpoint, consider doing so for the facets endpoint. While recently working on them, I added a log statement and had to take similar steps before being able to use it in QC.
Data services have a defined return type. So rather than plain text, if we use the existing endpoints, we'll have to put the string in a JSON property.
However, a new text-returning endpoint could accept a JSON parameter where each property is a parameter for the specified endpoint. I'm digging this approach.
Requirements:
List of details required for the completion of the issue or requirements for the feature/bug. This can also include requirements that lie outside of the teams such as new design docs or clarification from an outside source.
Needed for promotion:
If an item on the list is not needed, it should be crossed off but not removed.
[ ] Wireframe/Mockup - Mike
[ ] Committee discussions - Sarah
[ ] Feasibility/Team discussion - Sarah
[ ] Backend requirements - TBD
[ ] Frontend requirements- TBD
[ ] Are new regression tests required for QA - Amy
[ ] Questions
List of questions for discussions. Answers should be documented within the issue.
UAT/LUX Examples:
Example endpoints from LUX to use for development and testing, if applicable.
Dependencies/Blocks:
Blocked By: Issues that are blocking the completion of the current issue.
Blocking: Issues being blocked by the completion of the current issue.
If you implement this ticket, you will make Rob very happy!
Problem Description It's a pain to pull from the log, replace
\"
and\n
, then format. And it is a common task, either for myself or (to a lesser extent) Rob.Expected Behavior/Solution: Let's just provide a way to return it via new or existing endpoint. No need to actually perform the search.
If we end up doing this through the search endpoint, consider doing so for the facets endpoint. While recently working on them, I added a log statement and had to take similar steps before being able to use it in QC.
Data services have a defined return type. So rather than plain text, if we use the existing endpoints, we'll have to put the string in a JSON property.
However, a new text-returning endpoint could accept a JSON parameter where each property is a parameter for the specified endpoint. I'm digging this approach.
Requirements: List of details required for the completion of the issue or requirements for the feature/bug. This can also include requirements that lie outside of the teams such as new design docs or clarification from an outside source.
Needed for promotion: If an item on the list is not needed, it should be crossed off but not removed.
UAT/LUX Examples:
Dependencies/Blocks:
Related Github Issues:
Related links: