I'm currently interested in automation of some of our processes, so I need to query JIRA with REST. What I want to have in response is timespent of all users for a certain date. So I use the following queries:
search?jql=project=%my_project%22&updated>startOfDay(-1d)&updated<endOfDay(-1d)&fields=worklog
search?jql=project=%my_project%22&updated>%222014-08-19%22
but in response I get a lot of worklogs which was updated not only the date I pass as argument but a month before or a day after.
So I have several questions:
Am I understand right that if I track time for some issue then the updated field will be changed?
It is likely that my queries return issues which was updated for a given date in the first place. I mean if issue was updated - return it, but issue itself contains a lot of worklogs for some period of time (month I guess).
If it is true then can I limit worklogs for the issues for only given dates?
Thanks!
Yes, you are right, you can limit your query in a way like this. But I guess your syntax is invalid.
First, in both of your query, after the project part of the JQL, there's a single percentage sign, which cannot be interpreted as a char. I'm sure you wanted to write %22 there. (However, you can completely omit %22 char)
Second, the JQL part of your query string must be formed with the official JQL syntax in mind. That means when you use logical operators, like AND, then you must write that in the middle of the query. And also don't replace > with >. So, instead of
project=my_project&updated>%222014-08-19%22
the query must look like
project=my_project AND updated>2014-08-19
Note: & sign can only split the official query string parameters of the request.
Related
I am very fresh with Excel and still learning the basics. I came upon an issue I really need help with and couldn't find suitable solution online.
I have a column I keep on constantly updating with Bulk data THE COLUMN.
I'd like to see the most common entry and the least common entry for a specific time using this formula:
=INDEX('Data Input'!F433:F610,MODE(MATCH('Data Input'!F433:F610,'Data Input'!F433:F610,0)))
But once I try it, it constantly tells me:
Did not find value '' in MATCH evaluation.
I've tried with shorter ranges and It did work, so I guess once it runs through empty cell - it breaks. How can I modify this formula to function properly and print what I need?
And side question, is is possible to implement a calendar bar and choose between dates?
You can insert a clause to exclude blanks (assuming they are not to be considered a legitimate return):
=INDEX('Data Input'!F433:F610,MODE(IF('Data Input'!F433:F610<>"",MATCH('Data Input'!F433:F610,'Data Input'!F433:F610,{0,0}))))
Note that I have used
{0,0}
for MATCH's match_type parameter so that the formula will not error should there be more than one entry within your range which shares the highest frequency. In such cases, the above formula will return that which occurs first in your list.
I want to split a large number of JIRA issues into buckets automatically so that I can review a fixed fraction of them at a time via a JQL query. Unfortunately my options seem to be limited or nonexistent; one easy method would be to take the numeric portion of the key, modulo some fixed number N, but there's no modulo operator in JIRA (indeed, no arithmetic operators at all, just relational operators that return boolean values). Then I could execute a series of JIRA queries like this:
PROJECT = FOO AND HASH(KEY,12) = 0
PROJECT = FOO AND HASH(KEY,12) = 1
PROJECT = FOO AND HASH(KEY,12) = 2
...
PROJECT = FOO AND HASH(KEY,12) = 11
But there is no such thing; I can't extract various pieces of the creation date (day of the week, hour of the day, month of the year), and I'm stumped how I might do this.
The alternative is to manually maintain some kind of field like a label, and split the issues manually, but this is very tedious.
Any suggestions?
Although it does not exactly hash data, you can partition issues based on the issue number, which might potentially meet your needs. Caveats are that the order will be nonrandom, any gaps in the issue number sequence would produce partitions of different sizes, and you would need to know which issue number ranges you are targeting.
For example, the following JQL would extract two sets of 100 issues from the project FOO:
issue >= FOO-1 and issue <= FOO-100
issue > FOO-100 and issue <= FOO-200
If you have the third-party ScriptRunner app installed, you can also use JQL such as the following to match an issue field against a regular expression. For example, the following query would match all issues with an issue key ending in an even digit. You could extrapolate this to match against multiple digits of the issue key to create more than 10 ranges, or even try to apply the matching against a different field.
issueFunction in issueFieldMatch("", "issuekey", "[02468]$")
I was reading about Time-Based Versioned Graphs and came across the following example:
CREATE (s1:Shop{shop_id:1})
-[:STATE{from:1388534400000,to:9223372036854775807}]->
(ss1:ShopState{name:'General Store'})
My question: how do I calculate this date? from:1388534400000,to:9223372036854775807
Those two values are timestamps which in java are the number of milliseconds since the Epoch (1/1/1970) began. The second value is the maximum Long value, the end of Java time, a long way away.
There are ways in all languages for generating these values for specific dates (beware that some will be based on seconds), there is quite a handy list on this site.
If you are not working in any particular programming language and just want to enter queries then you can use an online date converter like this one.
You can also calculate timestamps in Cypher if you are working with dates that relate to Now somehow using the timestamp() function:
CREATE (s1:Shop{shop_id:1})
-[:STATE{from:timestamp(),to:9223372036854775807}]->
(ss1:ShopState{name:'General Store'})
IIUC to is just a Long.MAX_VALUE, and from can be a result of either calling timestamp() function via Cypher or setting the property with the value of System.currentTimeMills() via Java API.
Take a look at the example: http://console.neo4j.org/?id=43uoyt (Note that you can skip setting rel.to and use coalesce when querying instead).
With JIRA REST API there is at least 2 ways to get an issue:
/jira/rest/api/2/issue/{issueIdOrKey}
/rest/api/2/search?jql
I use both of them in my project but they return a slightly different results for updated field for the same issue.
Get by key: 2014-07-18T17:53:02.594+0300
Search: 2014-07-18T17:53:02.000+0300
By some reason milliseconds in search response are not set. It looks like a bug for me, but maybe there is configuration setting or something?
PS: I have the latest JIRA version (6.2.6)
JQL search results are generally fetched directly from the Lucene index, which stores timestamps with only millisecond resolution, whereas fetching the actual issue gets the date directly from the jiraissue table in the database, which can have sub-millisecond resolution (at least depending on your configured database).
EDITED: I see that I misread the precision above: the timestamp returned by getting the issue returns only milliseconds (vs nanoseconds) and the JQL query returns only integer seconds (vs milliseconds), so the Lucene data type linked above is not relevant.
However, the answer is still the same: JQL gets the result from Lucene, while an issue fetch gets the value directly from the database. On further investigation of why the Lucene index is not returning milliseconds: in the JIRA source in BaseFieldIndexer.indexDateField, JIRA calls LuceneUtils.dateToString(date) to convert the created field into a value that is indexable by Lucene. The dateToString method explicitly converts the field into an integer number of seconds (lopping off any milliseconds in the process), and it then converts the number to a String representation for indexing purposes.
Odd! I checked this with a 6.2 instance and also got a difference:
JQL: updated: 2014-07-11T19:34:04.000-0500
Key: updated: 2014-07-11T19:34:04.768-0500
I bet the code that returns the list of issues from a search uses a different date formatter that clears the milliseconds, whereas the one that returns the data from a single issue doesn't do that. I don't know of any configuration setting that would affect that.
I recommend filing it as a minor bug at http://jira.atlassian.com/browse/JRA
Minor because any code that is checking something based on ms seems unwise.
I'm trying to find all WorkItems that were assigned to a person X in the last 30 days.
The big problem I have is the "in the last 30 days"-part.
I thought about using the "ever" or "asof" keywords, but couldn't find a good answer yet.. something like WHERE [Assigned To] = 'X' AND (([Assigned To] != 'X') asof '<30daysago>').
But this is still not a bulletproof solution.
Any better ideas?
Thanks & kind regards
Simon
It appears that this is not possible using just WIQL, but you can get close.
The keyword #Today will give you today's date, then just subtract your range from it. The EVER keyword applied to [Status]='AssignedTo' and a comparison against a date 30 days in the past to [StateChangeDate] is what you'll need to accomplish this.
As close as you can get with WIQL and existing fields:
This says, from all revisions (status changes) return records where the user 'X' has ever been AssignedTo and the State has changed in the last 30 days. This will basically give you a slightly fuzzy picture of what your User has been working on in the last month.
WHERE [Microsoft.VSTS.Common.StateChangeDate] >= #today - 30
AND [System.AssignedTo] EVER 'Bennett Aaron'
ORDER BY [System.State]
Add the missing field:
You could add a custom field called AssignedDate that is captured during the New->AssignedTo workflow transition that you create in the Work Item Definition XML. You can accomplish this using the Team Foundation Server Power Tools extension to Visual Studio. This would give you exactly what you need as well as additional reporting options going forward.
TFS API
I cannot help you with this one, but I believe you could query using the TFS API.
A couple of quick gotchas I've experienced to save you time on ASOF and EVER:
AsOf won't help you by itself with this as it does not support a range of dates. It allows you to query as if it were another date. In other words, if you forgot to capture the results of a query yesterday, you can use an AsOf query to get the results that you would have gotten had it run yesterday. What I understand is that you want to query a basic date range.
EVER might not work as you expect against dates as I believe it uses the exact value of the field (timestamp portion of the date field would be included) it tests with. Just make sure the EVER keyword is used against the status field rather than a date.