I have a question on separating our JIRA Boards. Please see below.
Data Management Kanban Board
project = WFDM4 ORDER BY cf[10005] ASC
352 Issues
Data Landscape Kanban Board
project = WFDM4 AND labels in (dl_board) ORDER BY priority DESC, updated DESC
1 Issues
How can I edit the JQL for Data Management Kanban Board to separate the JIRA Kanban Boards?
Attempt:
project = WFDM4 AND labels not in (dl_board) ORDER BY priority DESC, updated DESC
259 Issues
There seem to be some missing issues in the new JQL since it is only returning 259 Issues. I would like these Kanban Boards to be completely separate.
Maybe the problem is because there are some issues without any labels.
When an issue has no label, all comparsions returns false, even when the comparsion is an negation.
Try this:
project = WFDM4 AND (
(labels is empty)
OR (labels not in (dl_board) )
ORDER BY ...
Related
In JIRA Board, only "stories" are showing
Filter for JIRA from (vertical3 dot > Board setting > General > Filter > Edit Filter Query)
project = NAP ORDER BY Rank ASC
Here I can see all the EPICS, STORIES, SUB-TASKS. I tried to change it to
project = NAP AND issuetype in (standardIssueTypes(), subTaskIssueTypes()) ORDER BY Rank ASC
NAP is project name
But, it is also same only. As standardIssueTypes(Bug, Epic, Story, Tasks) & subTaskIssueTypes(Sub-tasks), together is ALL
But, when I am going to board, it is still showing only "stories"
It seems there isn't any Database documentation for a given collection in TFS 2017 - e.g. DefaultCollection.
I can get WorkItems from dbo.vw_WorkItemCoreAll & dbo.vw_WorkItemCustomAll, but I can't seem to join on the AreaID that is given to tbl_Area.
What am I missing?
It appears the joining has changed for TFS 2017.
In general I would recommend using the TFS_Warehouse, if the database must be used at all. Areas in TFS_Warehouse are much more straightforward than the TFS_[YOURCOLLECTION] Database.
That being said, if you must use the actual raw database, then here's a query that will join the necessary info:
SELECT * FROM dbo.vw_WorkItemCoreAll w
INNER JOIN dbo.tbl_ClassificationNode c ON w.AreaId = c.Id
WHERE
id = SOMEID
ORDER BY w.Rev DESC
It appears that tbl_Area doesn't contain the actual classifications used for WorkItems anymore.
Disclaimer: This is a last resort - the MSFT preferred mechanism for obtaining this info is the TFS REST API, for the usual API reasons (flexibility, reproducibility, etc.).
In this case I wanted to run an SSRS report (didn't care if it broke in a few months), which works better on raw DBs.
I have a simple filter [ project = 'XXX' and issuetype in (Bug, Story) ] that I use for the Two Dimensional Filter Statistics gadget. It shows perfectly the number of Bugs and Stories per Sprint.
But, I would like to go down a bit by splitting the number of Bugs by priority, so it'll show the number of High Priority bugs, Low Priority bugs, and Stories per Sprint.
Anyone knows what is the query ?
To the best of my knowledge you can only get that kind of granular detail if you go per sprint.
Depending on how many Sprints you have (say 3) you may be able to make 3 Two Dimensional Gadgets and view all of them on your Dashboard (See picture for an example of one of the 3 in this case).
The query would then be:
project = 'XXX' and issuetype in (Bug, Story) and Sprint = 'YYY'
Pic:
Two Dimensional Filter Statistics (IssueType vs Priority) per Sprint
Using Jira 4.4 and Greenhopper 5.8.4
On the TaskBoard I'd like to show the total of story points for the column (state) rather than the total hours.
Any help would be appreciated.
Good question and obvious feature request indeed - I don't think that is currently possible and there is a related (though not identical) user story filed already:
As project manager, I'd like to customize the progress bar to show the progress in term of story points not cards count (GHS-2990)
It doesn't seem to have much attention yet, so to increase the chance of this being available you might add your vote/comment there to generalize this requirement and/or file a dedicated story addressing your use case specifically.
Please be aware though, that the Task Board has been scheduled to be superseded by the new and much more flexible Rapid Board, once the latter encompasses all features (well, guess most at least) currently available within the Task Board - see The Future of GreenHopper for details, it boils down to:
The Rapid Board removes the complexity of the existing user interface
(projects, contexts, boards, filters, versions, etc) while retaining
the flexibility of GreenHopper. In fact, with the Rapid Board,
GreenHopper is now a whole lot more flexible due to our use of the
JIRA Query Language.
Fortunately the GreenHopper team is approaching this transition in a defensive and compatible manner, but obviously I wouldn't expect any new features to be added to the now considered 'Classic Mode' either:
In GreenHopper 6.0 we plan to push the existing boards (Planning,
Task, Chart and Released Boards) to a Classic Mode and drop the
"Rapid" title. The existing functionality on the Planning, Task, Chart
and Released Boards will continue to be available for a number of
releases until it becomes clear that the majority of customers have
switched over.
I've created a Javascript solution to display storypoints on the Scrum/Kanban boards.
The script is attached to this jira issue.
As a temporary measure, I've written a SQL query to get this data:
select v.vname as theVersion, s.pname as statusName, sum(cfv.numbervalue) as totalStoryPoints
from jiraissue i
join issuestatus s
on i.issuestatus = s.ID
join nodeassociation a
on a.source_node_id = i.id
join projectversion v
on a.sink_node_id = v.ID
join customfield cf
on cf.cfname = 'Story Points'
join customfieldvalue cfv
on cf.ID = cfv.customfield
and cfv.ISSUE = i.ID
group by v.vname, s.pname
I've done some searching but have not been able to find out if there are any limits in TFS to the number of files in a single changeset.
This came up with IntelliJ IDEA where we found that it was splitting up changesets with >200 files. I want to argue that there shouldn't be any limit at all, or at least the limit should be the same as TFS' own limit, if there is one. See the defect I reported on this issue at http://youtrack.jetbrains.net/issue/IDEA-54846.
The number of changes in a changeset is stored as the CLR's int type. So there's definitely an upper limit of int.MaxValue or 2,147,483,647. I don't think there are any checks to limit the number of changes in any other way (though I may be mistaken.) Realistically, you probably have disk space contention to deal with on the server long before you reach that value.
One of the specific design goals of Team Foundation Server was to deal with large changesets - particularly merging large feature branches with a lot of churn - which can produce a changeset with a large number of merge or merge/edit changes.
In short, no. And even if there was, hundreds is several orders of magnitude off. There should be no reason to split them into multiple changesets - you only do yourself a disservice by doing that. You're hurting traceability by doing this and basically devolving into a non-atomic system (yay, CVS!) and makes the state of your repository unreliable. It negatively impacts continuous integration, linking to work items and builds and overall traceability. Imagine checking in half your merges to a branch... then the other half. That sounds like a nightmare.
Based on my observations for our TFS site, the number of files in a TFS changeset is at least 11670.
USE Tfs_Warehouse;
GO
SELECT
FCC.ChangesetSK
, COUNT(1) AS row_count
FROM
dbo.FactCodeChurn FCC
INNER JOIN
dbo.DimChangeset DCS
ON DCS.ChangesetSK = FCC.ChangesetSK
INNER JOIN
dbo.DimFile DF
ON DF.FileSK = FCC.FilenameSK
GROUP BY
FCC.ChangesetSK
HAVING
COUNT(1) > 200
ORDER BY
2 DESC;
Partial results
ChangesetSK row_count
53172 11670
4436 7940
4442 7808
43808 6262
21016 6047
53173 5835