WorkFront/AtTask API $$ TODAYe + 6m缺陷？

的workfront API没有返回相同的结果。我们的网络报告：

论workfront我们的web前端的一个报告具有$$TODAYbw到$$TODAYe+6m日期范围和它返回约5〜50行。

我想在这样的API（格式为便于阅读）像

/v7.0/RSALLO/search 
?fields=DE:project:Probability,allocationDate,scheduledHours,project:name,project:status,roleID,project:status,role:name 
&allocationDate_Mod=between 
&allocationDate=$$TODAYbw 
&allocationDate_Range=$$TODAYe+6m 
&AND:0:project:status_Mod=notin 
&AND:0:project:status=CPL 
&AND:0:project:status=DED 
&AND:0:project:status=REJ 
&AND:0:project:status=UZF 
&AND:0:project:status=IDA 
&AND:0:roleID_Mod=in 
&AND:0:roleID=55cb58b8001cc9bc1bd9767e080f6c10 
&AND:0:roleID=55cb58b8001cc9bd9fc0f8b03a581493 
&AND:0:roleID=55cb58b8001cc9bfaa01243cd6024b6d 
&AND:0:roleID=55cb58b8001cc9c0afa399dece405efd 
&$$LIMIT=1000

它几乎没有返回任何结果相同的查询。请注意0一行。如果我将其更改为=$$TODAY+6m而没有结束日期修饰符，则API返回〜500行。

我经历了每个过滤条件，它只是出现错误的allocationDate范围。我发现日期修饰符为this resource，其中没有e+6m示例，但它适用于我们的Web前端报告。

API是有缺陷的还是网络报告在后台做了额外的事情？

来源

2017-06-02 Zorgarath

我没有针对您的问题的确切解决方案，但是我可以确认API解析通配符时遇到了一些难题，例如您正在尝试使用，并且它们并不总是按照我们的预期方式出现。此外，API不会像文本模式报告那样解析事件，因此后者看起来很棒的查询可能会在前者中返回不同的内容。

如果我可能会提出一个不同的解决方案，因为您已经在Workfront之外对此进行了编码，那么我建议您只需自行执行日期计算，并将明确的日期时间对象传递给Workfront，而不允许它使用自己的逻辑。我知道这并不回答“什么是查询将完全返回我想要的”的问题，但它应该给你正确的最终结果。

为了什么是值得的，我花了大约15分钟试图得到一个工作在我的最终的例子，我放弃了它不断返回应该超出我自己的日期范围的值。

来源

2017-06-05 15:31:09

感谢您的确认。解决方法与您的建议一样，让应用程序计算出日期时间，然后将其传递给API，但它确实将Web报告转换为自定义程序更乏味。 – Zorgarath

如果API返回了从请求中解析出的参数列表，那也是很有用的。这样我们可以看到它正确添加了哪些值。 – Zorgarath

我同意你的第二条评论。我试图看看一些返回的时间戳来解析它在做什么，但就像我说我很快就对它感到恼火。由于您已经构建了一些查询，因此您处于更困难的位置，但是如果日期时间查询是唯一棘手的问题，那么将这些少数项目转换为代码内解决方案不应该是世界上最糟糕的事情。也许别人会过来处理这种挫折，并有更多相关的建议。您也可以尝试官方的Workfront论坛。 –

WorkFront/AtTask API $$ TODAYe + 6m缺陷？

回答

相关问题