【问题标题】:Gmail API Watch not filtering by LabelGmail API Watch 未按标签过滤
【发布时间】:2015-08-15 23:07:28
【问题描述】:

我正在将 Gmail 推送通知与 Google PubSub 一起使用,并且有一个我想要监控任何更改的自定义标签。我使用以下代码为标签注册手表(标签的Id为Label_1)

WatchRequest wr = new WatchRequest();
wr.TopicName = "projects/" + primaryLink.ggProjectId + "/topics/iLink" + segmentId;
if (labels != null && labels.Count > 0)
{
    wr.LabelIds = new List<string>();
    wr.LabelIds.Add("Label_1");
    wr.LabelFilterAction = "include";
}

WatchResponse wrr = gs.Users.Watch(wr, emailAccount).Execute();
return "HistoryId " + wrr.HistoryId.ToString();

}

手表注册正常。问题是我会收到任何 Gmail 更改的推送通知,而不仅仅是标签下的更改。

是否支持自定义标签?

【问题讨论】:

  • 用户标签也应该可以正常工作。您确定不是对有Label_1的消息进行了不同的标签更改吗? (例如,Label_1 消息被标记为未读,但该消息上的 Label_1 未更改。)
  • 例如在发送电子邮件时不会发生 - 这与标签无关。最初有一个未指定标签的用户手表。新的监视命令(带有标签过滤器)是否会覆盖以前的监视?我还尝试在新命令之前调用 Stop()?
  • 一个 watch() 应该覆盖前一个。您可以调用 stop() 并将其保留一段时间以确保旧的已消失(在这种情况下,新的 watch() 不会覆盖旧的将是一个错误)。
  • 我可以确认这仍然在 v1 中发生。
  • @PNC 此错误有一个谷歌问题跟踪器条目。您能否通过引用issuetracker.google.com/issues/36759803 来更新您的帖子,并附上注释来为该问题加注星标?为它加注星标的人越多,它就越早得到修复。

标签: gmail-api


【解决方案1】:

我注意到了同样的问题,但后来发现这是因为 API 的工作方式。您可以通过 LabelIds 过滤电子邮件,但只有当电子邮件被直接过滤到选定的自定义标签时,您才会收到通知。我猜它的设计而不是 API 中的缺陷。

要对此进行测试,请在 Gmail 中创建一个自定义过滤器,它将您的自定义标签直接应用于一组电子邮件,您应该会收到这些电子邮件的通知。

已编辑(2015 年 6 月 11 日): 推送通知会向您发送 HistoryID 和用户的邮箱名称。作为响应,您的端点应该调用 userhistory.list() 并带有您想要监控更改的 HistoryID 和 LabelId。

$opt_param = array();
$opt_param['startHistoryId'] = $historyID;
$opt_param['labelId'] = $labelID;
$opt_param['fields'] = 'nextPageToken,historyId,history/messagesAdded';

$service->users_history->listUsersHistory($userID, $opt_param);

上面是一个 PHP 代码 sn-p 用 historyID 和 labelID 过滤历史列表。

【讨论】:

  • @PNC 问题是 watch() 钩子只为您获取每个事件的 HistoryID 和邮箱,无论您在创建监视请求时指定什么 LabelId。 historyID 是邮箱范围的 ID,而不是 LabelID 范围的。因此,无论标签的任何内容发生变化,HistoryID 都会递增。为了响应推送通知,您的端点应该调用 historyList.list()。在这里您可以过滤带有您想要监控的 labelID 的消息。
  • 我从 Google 团队之一那里获得了以下更新:“您应该能够像您指定的那样通过标签 ID 限制 watch(),但我可以确认它不起作用现在为 user 标签。逻辑和错误相当复杂,我们正在努力,但没有 ETA"
  • Google 曾经修复过这个问题吗?我仍然有同样的问题,过滤器不起作用。
  • 截至 2020 年 1 月 20 日仍然存在问题。浪费了一整天的工作。是的
  • 截至 2020 年 4 月 18 日仍有问题
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-25
  • 2012-11-28
  • 1970-01-01
  • 2011-09-15
  • 1970-01-01
相关资源
最近更新 更多