Jira的高级应用—扫雷篇

本文做为Jira深入学习的最后一篇博文，让我来给大家好好介绍下我在整个Jira使用和开发过程中遇到的那些坑，防止后面的兄弟姐妹不要跟我一样炸死在沙滩上。

 

第一坑：Jira Restful接口版本的问题

Jira的Restful接口格式如下：http://ip:port/rest/api/${version}/{模块},例如我要做查询时需要调的接口是http://ip:port/rest/api/2/search 2代表的是restful接口的版本。

我在开发我公司的Jira产品时，我们公司的Jira版本是6.2,我自己搭建了一套7.1的版本供我开发和调试代码用。虽然我开发用的版本7.1比公司现网的6.2版本要高，但是他们的rest版本都是2。但是，当我开发调测完切换到Jira6.2以后，我的内心是崩溃的。明明调测好的代码怎么各种报错？后来才发现7.1与6.2虽然rest版本是一样的，但是rest的报文不一样。

举例：

在7.1中你在创建issue指定issuetype时，http的请求可以是这样的："issuetype":"32"

而在6.2中http的请求需要这样的："issuetype":{"id":"32"}，如果按照上述方式会报bad request错误。

所以从这一刻，我果断弃坑，把我开发版本也改成了6.2，所以本篇文章介绍的所有Jira的坑在6.2我是验证过的，不排除他们后面版本已经修复了。

 

第二坑：Jira的渲染器

Jira自带一个富文本的渲染器，可以把文本框搞得漂漂亮亮，看起来是这样的：

但当我书写和编辑时，画风是这样的：

很明显它的编辑方式真的不是很友好，所以这个渲染器基本是个摆设，因为用起来真有种便秘的感觉，甚至Jira自己都默认关闭了多行文本框渲染功能。

如果你通过rest取带有渲染器的属性时，一定要使用renderedFields属性(https://blog.csdn.net/yejingtao703/article/details/87479490中有介绍过)，它会帮我们转换成html格式，否则你拿到的也是上图的这种很蹩脚的文本。

 

第三坑：时间类型的混乱

Jira接口中带时间的日期到底怎么传？我翻了各种资料，开发过程中也碰的头破血流，到最后终于杀出重围。原来不同接口，时间要按不同的格式传。我只想说一句，这个坑，不能忍~~~！

3.1做为查询条件（long类型）：

假如你想添加大于某个时间的判断，是这个样子的：cf[10252]>{当前的毫秒数}，在java中获取当前的毫秒数是System.currentTimeMillis()

3.2做为查询结果（文本类型）：

结果中返回给你时间是如下样子的"2012-10-01T09:45:00.000+02:00"，对应的DateFormat是这个格式的"yyyy-MM-dd'T'HH:mm:ss.SSSZ"

3.3做为创建issue的参数（文本类型）：

在创建任务给某个时间类型的字段赋值是这样的"customfield_10252": "2012-10-01T09:45:00.000+02:00"，跟查询的格式是一样的

其它的场景我还没试验过，我就想说就不能统一一下么，一会儿long一会儿文本，每次传错了就返回给我一个bad request，调测时间太头疼了吧。

 

第四坑：Jira中的特殊符号

Jira中隐藏了很多敏感符号，我踩到一个卡了我好久。我有个场景是要用git地址去查询任务，cf[10252][email protected]:project.git，但是讨厌的bad request又来了，一旦加入这个条件就报404错误。后来我发现这个@符号在Jira里是敏感字符，如果用到这种符号时需要给属性在外面多封装一圈单引号才可以！cf[10252]~'[email protected]:project.git'

目前我这遇到过@，其它的还没发现。

 

第五坑：Jira search接口的查询结果

Jira的search接口我们可以在fileds中自定义返回的属性，例如："fields":["id","key","reporter","customfield_10252"]，代表我们想拿到这个issue的id、key、报告人、还有一个自定义属性。

我在使用中遇到过明明我自定义属性是有值的，但是我通过search接口查询出来的这个属性怎么永远是空呢！！后来我发现，我fields中自定义属性写错了，写了一个不存在的customfield_99999，但是一直喜欢bad request的Jira既然这次不给我404了，它没有任何的报错并成功返回给了我response，只不过在返回体中直接丢弃了customfield_99999的信息。

我不知道Jira是基于什么考虑设计成这样的，作为开发者来说一旦手误写错了customfield是很难第一时间发现错误的。

 

第六坑：Jira工作流的不足

在选择要不要使用Jira时，要先考虑自己的应用场景，你打算拿Jira来干什么。如果只是做任务跟踪，做简单的工作流，那欢迎使用Jira。如果用来做OA或者更复杂的流程管理，那请果断放弃Jira，因为它并不支持复杂的流程调度。

Jira的工作流，不支持环节中人员的竞争和协作，不支持环节间的并行，不支持任务分配到组织机构，所以如果对workflow有更高级的要求请选择BPM协议的流程引擎，推荐Activity。

 

好了，这一系列四篇博文就是这两月对Jira的一些知识积累，关于Jira的研究和分享就告一段落了，希望能对大家的工作有所帮助吧。