C# 工作面/附件API$$TODAYe+6m缺陷？

workfront API返回的结果与我们的web报告不同：

在我们的web前端workfront上，其中一个报告的日期范围为$$TODAYbw到$$TODAYe+6m，它返回了大约500行

为了便于阅读，我在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

几乎没有任何结果。请注意&allocationDate_Range=$$TODAYe+6m行。如果我将其更改为read=$$TODAY+6m，而不使用一天结束修饰符，API将返回约500行

我检查了每个筛选条件，只有allocationDate范围出错。我找到了日期修饰符，其中没有e+6m示例，但它可以在我们的web前端报告中使用

---

API是否有缺陷，或者web报告是否在后台做了额外的工作

对于您的问题，我没有一个确切的解决方案，但我可以确认，API在解析通配符时确实有一些困难，就像您尝试使用的通配符一样，而且它们并不总是按照我们预期的方式出现。此外，API的解析方式与文本模式报告不同，因此在文本模式报告中看起来很好的查询可能返回与前者不同的结果

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

---

值得一提的是，我花了大约15分钟的时间试图让一个示例在我这方面发挥作用，但在它不断返回本应超出我自己日期范围的值后，我放弃了。谢谢您的确认。解决方法如您所建议的，让应用程序计算出日期时间，然后将其传递给API，但这确实会使将web报表转换为自定义程序变得更加繁琐。如果API返回从请求解析的参数列表，这也会很有用。这样我们就可以看到它正确地添加了哪些值。我同意你的第二条评论。我试图查看一些返回的时间戳来解析它在做什么，但正如我所说的，我很快就对它感到恼火。由于您已经构建了一些查询，因此您的处境更为困难，但是如果datetime查询是唯一棘手的事情，那么将这几项转换为代码内解决方案不应该是世界上最糟糕的事情。也许会有其他人出现，他们以前曾处理过这种挫折，并提出了更相关的建议。你也可以试试官方的工作区论坛。