I wrote a Rally app to do reporting on TestSets and TestCases. Suddenly today, my app was not getting any TestCases in it's query.
To simplify this, I will take my app out of the equation and I am just running queries with the web service api: https://rally1.rallydev.com/slm/doc/webservice/index.jsp?version=1.40
If I query a TestSet, the TestCases field, which should contain a list of the TestCases in the TestSet, is coming back empty for TestSets that definitely have TestCases. This was working perfectly up until sometime in the last few days (we used the app today and weren't getting any TestCases when the last time we used it, we were and no changes have occurred on our end).
If I look at Test Cases in Track->Iteration Status in Rally and expand the TestSet to see all the TestCases, they show up. So they are there, just for some reason the web service api isn't returning them.
I've spent the last two hours reading the API documentation and searching Google to see if anyone else has had this issue or if anything might have changed that is causing this, but I haven't found anything.
I have confirmed that other objects containing a list of TestCase objects (such as TestFolders) are properly returning a list of TestCases. I have also confirmed that I am able to query the individual TestCases that should be returned in the list. I have also confirmed that I am able to query the TestCaseResult for the particular TestSet and TestCase.
So I am really stumped. It appears as though it's just TestSet.TestCases that isn't working and I am unable to find any specific cause or correlate something unrelated that could be the cause.
Any thoughts?
Rally's DevOps team issued a fix for this issue the evening of 10-jan-2013. TestSet queries through WSAPI should be appropriately hydrated with member TestCases again. Contact Rally Support with any questions or concerns.
This is a bug - Rally's engineering team is aware of the problem and is working on a fix. Please file a Case with Rally Support to report/get status updates on the Defect resolution.
Related
For some odd reason the results that I am getting from the Graph Security API the past two days are inaccurate and I can't for the life of me figure out why.
If I query https://graph.microsoft.com/v1.0/security/alerts I am returned 7 old alerts without any obvious relationship, rhyme, or reason for populating my results. These are not the 7 most recent, and we have had more than 7 alerts.
For example, when attempting to append $filter=vendorInformation/provider eq 'Microsoft Defender ATP' I receive:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Security/alerts",
"value": []
}
This issue appears to extend for me across all of the MTP services.
I can see the alerts within MDATP, and others like MCAS and ASC for example when navigating directly to those portals or querying their platform specific api's, like
https://api-us.securitycenter.windows.com/api/alerts for example.
I am getting data returned, it is just not the right data.
I am utilizing a Postman App registration with the SecurityEvents.Read.All and SecurityEvents.ReadWrite.All "Granted for MYDOMAIN".
I feel like I am missing something here. Any one else having issues? More than happy to share additional details that would be useful.
Thank you for your feedback. Our MDATP team has identified and fixed the issue and it should now work as expected.
We have an ASP.NET Core Web API project. Today on accident I found an API method that was returning unnecessary amounts of data.
In my example we were returning users along with countries which is what we needed, but we were also returning a list of cities for each country so that was a tremendous amount if data, I was able to reduce it from 7MB to 23KB (per Insomnia client).
I was able to fix this by performing a select and creating a new country object and not passing in the cities property. I am not even sure if that's the right way to fix that problem but I will leave that for another time. My question is...
Is there a tool/nuget package out there that would provide this type of info? I'd like to get an idea on how much data we are sending to the clients when different methods are called. We have app insights but I don't believe it provides that data or at least I don't see it.
Thank you!
I was able to resolve this issue by writing some middleware code that logs the results to azure application insights, here is a copy of the code if anyone needs it:
https://gist.github.com/tekguy/52b245f6582158d7240f80bf46c4cc71
You can then query this info by using app insights log query:
requests
| order by timestamp desc
| project url, customMeasurements.Size
I started modifying/developing Rally apps about a week ago using the existing Rally apps provided on the Github repository so far. However, for one of my final tasks I've been asked to recreate a tailored Defect Trend Report App and unfortunately, the source code is not available for the App. I tried to start from scratch but I've ran into numerous errors and am a bit overwhelmed.
I was wondering if anyone had the src code for the app or knew of a way to extract the src code from the existing app. Of course if there is custom code that an individual has worked on that could also help me progress in this process and wouldn't mind sharing it, that'd also help a ton.
I saw that there were a few snippets that could be used from the Hackathon repo, but they're not quite on the mark of what I want to do with the app. I'm just trying to have the existing app filtered by delivery versions (currently filtered by iteration/release).
All help is greatly appreciated.
Thanks fellas!
There is an example of a 'bare metal' chart app in the App SDK 2.0 docs. It should give you the basics on how to do a chart.To get to it, go to the help pages (click on avatar in top right corner) and search for "Rally App SDK"
After that, you need to work out how to select defects from the various releases and do a count of each. There are two ways to do this:
Get all defects in the project you are in (don't forget whether you need to scope down to child projects too) and then do something like _.uniq() on the release field to find the list of releases (or do another request to get all the releases into a different store and use that for names and a count).
Get the releases and then for each release request the related defects.
If you do ask for child projects, you will need to handle all the scenarios of different releases for different projects - can get complicated!
#1 is effectively one big fetch, #2 may be many smaller ones.
You may want to decide whether to count all defects, sum the estimates, ignore those not finished, etc., etc.
I'm a freelance web dev and I work with a lot of clients across many different workspaces in Asana. Not being able to get a consolidated view makes this a tedious and difficult thing to manage, so I'm putting together my own little utility to help me get a 'superview' of tasks assigned to me in order of the due date. In order to make this easier for me to scan, I need to have the project name next to the task details.
The easiest way, in my mind, would be a single API call for all tasks assigned to me and request the project name, task name, task id, due date, and workspace name all at once.
The API doesn't seem to allow this consolidated type of request, however, so instead, the workflow goes something like this;
API call to get all my workspaces
Loop through the workspaces, making an API call for each to get all tasks
Use PHP to sort those tasks accordingly
Loop through those tasks making an API call for the first instance of each project in order to get the project name (I cache the data as I
go so that I'm only making a call once per project)
The issue I'm getting is a 500 error when I start making API calls to get the project details. I doubt I'm hitting the 100 call per minute limit, but I'm still getting the errors none the less. In light of this, I'm looking for a way to make a consolidated call that contains all the data I need, but I can't seem to figure it out.
Anyone have some guidance on this?
Good news! We actually do support Input/Output options that allow you to specify which fields you want, including nested fields. So, while you still need to make separate calls for each workspace, you can do something like this:
workspaces = GET /workspaces
for id in workspaces
tasks = GET /workspaces/:id/tasks?assignee=me&opt_fields=name,due_on,projects.name
(If you're only interested in incomplete tasks, you can add &completed_since=now - or if you want incomplete and recently completed tasks, &completed_since=... with the timestamp you want to exclude any tasks that were completed before)
Additionally, 500 is not the code we send for rate limiting - it's likely an issue with the request itself. How are you requesting the project details?
I'd been looking at using the Rally API to create an app to do some simple auto-ranking stories based on specific criteria (at the request of / to help out a couple of our Product Owners) in a drag&drop workspace.
I did this by adjusting the "Rank" properties of the sequence of stories (I made sure to keep the rank values within the same overall min / max range as prior to the auto-reorder). I made a call to the API to update each story's rank individually (in quick succession).
Testing the app, I found that sometimes after running the auto-ranking app, some screens (such as the kanban board) would tell me that "drag and drop re-ranking is disabled for manual rank workspaces" (and the kanban would no longer let me drag & drop, although other screens such as the backlog would still let me drag & drop, and the workspace settings were still set to drag & drop). Deleting the stories, or reordering them on the backlog screen would return things back to normal.
After trying a few ideas to solve this, I figured perhaps if I was updating the Rank on a number of stories in quick succession, the back-end might be getting confused with these (potentially several / concurrent) requests. Introducing a delay between each story's API call has seemed to avoid the problem, and to speed things up, I now update a story's rank in the API only after the previous story's rank update has invoked the "updateComplete" function.
Do the assumptions in the last paragraph above make sense based on the backend ranking? Is there any Javascript API call to update multiple stories at once? (Otherwise I'm quite happy with the solution of only calling the API "update rank" after the prior API "rank update" call has returned ok).
That sounds like you discovered a possible issue with the backend ranking. The warning you were getting stems from the board trying to figure out which type of workspace you are in (manual or dnd rank). Since that setting is not currently available via WSAPI the board tries to figure it out based on its data and sometimes gets it wrong.
Currently there is no fully supported/documented way to adjust the ranks of items via WSAPI. The Card Board component in the App SDK uses special rankAbove and rankBelow query string parameters during update calls (which you can see in Firebug or the Chrome dev tools).
How are you currently setting the Rank values?