I'm looking to fetch all repo commits from a specific user/author and I can't quite get my head around the filtering documentation from Atlassian.
Entering this in my browser (with the placeholders changed for my project) lists out 30 items from my project.
https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/commits
But I want it to list out only the commits authored by myself. I've tried all sorts or variations like:
.../commits?q=reviewers.nickname+"marknotton"
.../commits?q=user+%3D+"marknotton"
.../commits?author="marknotton"
Every variations just returns the same results. My url params are ignored, presumably because they are invalid. This could just be a silly syntax issue? Are there any examples I could refer to for help?
https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/commits?state=merged&username.1=marknotton&role.1=AUTHOR
Related
I am using JIRA GET /rest/api/3/search And I want to filter issues by their priority, but using this URL does not work. https://MyJira.atlassian.net/rest/api/2/search??jql=priority="Low" I am really new, so sorry if my question is very basic.
I tried different filters but it is returning all the results
You're almost there; just use "Low" without quotes:
https://myjira.atlassian.net/rest/api/2/search?jql=priority=Low
And as additional resource on Priority field and all other JQL operators&fields, you can check this Atlassian documentation page.
When using the typeahead endpoint to search for projects in my Personal Projects workspace, it returns all of my projects. The results don't change for different queries and the count parameter is ignored. I don't have this problem for other workspaces/organizations. Is this expected since Personal Projects are special or is this a bug?
(I work at Asana)
To answer the question, yes it is a bug. But also, in general you can expect issues when dealing with Personal projects as they are indeed special.
We've addressed the filtering issue and the results you get should be filtered by query (required) and count (optional) now. Thanks for reporting!
I want to know how many people have visited a particular isssue in order to know its popularity( I can't trust on number of watchers of the issue) .Is there any way (JiraDB or anything) by which i can know how many people(just the count) have visited any particular issue.
The question can be modified like this : Top 10 mostly visited issues in a week or so.
Seb's earlier answer provides a possible solution for JIRA Cloud. I am not aware of any off-the-shelf product for behind-the-firewall installations of JIRA, and I do not believe that views are tracked anywhere in the JIRA database.
For behind-the-firewall instances, you could certainly write a script to parse the JIRA access logs (stored in $JIRA_HOME/logs/access_log*) to count issue accesses that way.
The JIRA access logs are stored in a format that is similar to the Apache access log format, so you just need to parse out accesses to individual issues by looking for URLs of the format "http://MYJIRA/browse/ABC-123".
Out of the box this is not possible. Jira does not log view counts for single issues.
You could have a look if there is any plugin for this at https://marketplace.atlassian.com/search?application=jira
E.g. https://marketplace.atlassian.com/plugins/communardo.connect.usage.statistic.addon looks like it could fit your requirements, but I personally have never heard of it.
I need to search records in JIRA by using jira key. I am able to search issues but I have to do one more task that is to find out resolved by and resolved date. I had did lots of goggling but did not find content which satisfied me.
I really appreciate to help me to solve out this problem.
Thanks,
You could do this with a calculated field using Script Runner to extract the information from the Issue History tab. Not sure how good the search is using that approach. Alternatively you can use the REST API and a script to scan issues, but that's probably too slow.
Finally I am able to solve out this problem by traversing history data. I used json call to pick history data on basis of jira key then I converted that history data into typed history collection and started looking for Resolved token. When I got Resolved token in history then I picked the assigned name. By this way I am able to solve out this problem.
Thanks for your support.
I am using the following API call to pull all of the videos with <TAG> from <CHANNEL>:
http://gdata.youtube.com/feeds/api/users/<CHANNEL>/uploads/-/<TAG>/?v=2&alt=jsonc&start-index=1&max-results=50&orderby=published
But for some tag names the results are wrong, or even empty. For example
http://gdata.youtube.com/feeds/api/users/NintendoFR/uploads/-/n3ds/?v=2&alt=jsonc&start-index=1&max-results=50&orderby=published
only has 1 result, but I know that there are at least 20 videos with the tag "n3ds", on the other hand
http://gdata.youtube.com/feeds/api/users/NintendoFR/uploads/-/wiiu/?v=2&alt=jsonc&start-index=1&max-results=50&orderby=published
gives the expected 36 results. Any ideas? Or anyone with similar problems?
Have the same problem (search by tag no longer works).
The Youtube API team has history for making un-announced changes.
For example, a few month's back, the "video description" field was truncated
- without any announcement of the change
- without updating the doco to reflect the change
This looks like a similar change, i.e. tag search has been depreciated (switched off).
Workaround (for your videos) is to include the tag(s) in the first 150 chars or so of the video's description.
We have a similar problem. A few days or weeks ago, a piece of code that sends these requests stopped delivering results. After a bit of research, we found out that getting results is random:
On some occasions we get the right results
On some occasions we get no results.
The only difference we could find in both requests is that a parameter is missing from the requests. When requesting an answer in XML, in the feed node an item is missing:
<feed xmlns:media='http://search.yahoo.com/mrss/'></feed>
Although we do not know why this is, at least now you know that you are not the only one that has this problem.