1

在我看来，.message_route(...) 的默认行为之一（即第三次尝试获取消息路由：“回退到提供的参数，如果它们有效”）无法正常工作。

它应该将主题解析为 [ID] 之类的表达式，以用作“thread_id”来发布消息。到目前为止，一切都很好。

问题是消息在到达这一点之前（当然）在 .message_parse(...) 中被解析，这使得当以这种方式获取“thread_id”时，我们最终得到一个 unicode-string 而不是所需的#ID 为整数或长整数。

我是对的还是我在这里遗漏了什么？

def message_route(self, cr, uid, message, model=None, thread_id=None,
                  custom_values=None, context=None):
[...]
    3. Fallback to the ``model``, ``thread_id`` and ``custom_values``
       provided.
[...]
# 3. Fallback to the provided parameters, if they work
    if not thread_id:
         # Legacy: fallback to matching [ID] in the Subject
         match = tools.res_re.search(decode_header(message, 'Subject'))
         thread_id = match and match.group(1)
     assert thread_id and hasattr(model_pool, 'message_update') or hasattr(model_pool, 'message_new'), \
         "No possible route found for incoming message with Message-Id %s. " \
         "Create an appropriate mail.alias or force the destination model." % message_id
     if thread_id and not model_pool.exists(cr, uid, thread_id):
         _logger.warning('Received mail reply to missing document %s! Ignoring and     creating new document instead for Message-Id %s',
                         thread_id, message_id)
         thread_id = None
     _logger.debug('Routing mail with Message-Id %s: fallback to model:%s, thread_id:%s, custom_values:%s, uid:%s',
                   message_id, model, thread_id, custom_values, uid)
     return [(model, thread_id, custom_values, uid)]
4

0 回答 0