• Jérome Perrin's avatar
    rss_style: include guid in tickets RSS · df57bbe4
    Jérome Perrin authored
    SlapOS ticket RSS have one entry for each ticket, with the content of
    the latest event as description, but when using a feed reader application,
    we'd like to have a new entry for each message posted to the ticket, to
    be notified that a new message was posted.
    
    Feed reader applications fetch the RSS and have to determine if each
    entry is already in their database or not. In a scenario like below, we
    observe different behaviors for different applications:
    
      1. a user open a ticket "help" with a first message "I need help !".
        The RSS entry for this ticket is:
    
        <item>
          <link>https://slapos.example.com/#/support_request_module/1</link>
          <title>Help</title>
          <pubDate>Mon, 01 Jan 2001 10:57:10 +0100</pubDate>
          <description>I need help !</description>
        </item>
    
       => feed reader fetches the RSS and add a new entry with title "Help"
    
      2. support operator reply with a second message "how can I help you ?"
        The RSS entry for the ticket becomes:
    
        <item>
          <link>https://slapos.example.com/#/support_request_module/1</link>
          <title>Help</title>
          <pubDate>Mon, 02 Jan 2001 08:32:12 +0100</pubDate>      <== this is different
          <description>How can I help you ?</description>           <== this is different
        </item>
    
    now depending on the implementation of the feed reader, it will either:
    
     - add a new entry, this is the best behavior. In the RSS readers I tested,
      liferea and newsboat do this. Probably they consider that the entry is
       different because it has a new pubDate and/or description.
     - update the existing entry "in place" - this is not so good, because
      this does not appear as a new entry and the original message is no
      longer in the RSS reader. TinyTinyRSS behaves like this (at least in
      version 17.4, which is a bit old)
     - consider they already have the entry and don't do anything - this is
      even worse, because user can not see there was a reply. FreshRSS
      behaves like this.
    
    A RSS for tickets will always have the problem that the feed reader must
    refresh often enough if we want to have a copy of all messages in the
    feed reader (and that's why ERP5 CRM's uses a RSS of Events and not
    Tickets), but we can make this situation better by using guid on messages.
    
    By constructing a guid [1] that will become different every time a new
    message was posted, feed readers consider each item as a a new, different
    entry. At least this is the case for all the feed reader I tested, except
    ERP5 builtin feed reader which only consider the `link` attribute.
    
    Strictly speaking this implementation has a "problem" that these guids
    are not permalinks, but I believe that's something we should address in
    erp5_rss_style (if guid does not look like an URL, set isPermalink="false"),
    but in practice it does not seem to be a problem.
    
    1: https://validator.w3.org/feed/docs/rss2.html#ltguidgtSubelementOfLtitemgt
    df57bbe4
Name
Last commit
Last update
..
RegisteredSkinSelectionTemplateItem Loading commit data...
SkinTemplateItem/portal_skins Loading commit data...
bt Loading commit data...