1. 14 Dec, 2021 1 commit
  2. 10 Dec, 2021 9 commits
  3. 09 Dec, 2021 2 commits
  4. 07 Dec, 2021 1 commit
  5. 06 Dec, 2021 3 commits
    • Rafael Monnerat's avatar
      rss_style: include guid in tickets RSS · f62ccafe
      Rafael Monnerat authored
      See merge request !351
      f62ccafe
    • 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
    • Jérome Perrin's avatar
      grid/utils/setRunning: detect the case where pid has been recycled · 19b3eac1
      Jérome Perrin authored
      It can happen that slapos can be terminated without removing the pid
      file, and another long running process using the same pid from the one
      in the pid file is running, which cause slapos node to never run.
      
      This makes setRunning a little bit clever, by ignoring the process
      unless it also has `slapos` in its name.
      19b3eac1
  6. 02 Dec, 2021 1 commit
    • Julien Muchembled's avatar
      slapos.cfg.example: clean up [networkcache] · 3ed62713
      Julien Muchembled authored
      When using HTTPS, slapos.libnetworkcache uses exclusively the client certificate
      (which must be configured) so https://*.nxdcdn.com can't work from slapos.libnetworkcache
      
      And without download-dir-url, download-cache-url is quite useless.
      
      Reorder options to clarify the difference between upload & https.
      3ed62713
  7. 25 Nov, 2021 1 commit
  8. 24 Nov, 2021 2 commits
  9. 23 Nov, 2021 1 commit
  10. 22 Nov, 2021 2 commits
  11. 19 Nov, 2021 1 commit
    • Jérome Perrin's avatar
      Fix promise output when falling back to SR python · e2cebc0c
      Jérome Perrin authored
      On python3 slapos.core for python2 software release, the output was bytes:
      
      ```
      2021-11-05 17:28:39 slapos[12654] INFO Error with promises for the following partitions:
      2021-11-05 17:28:39 slapos[12654] INFO   slappart7[balancer]: b'Promise \'check-apachedex-result.py\' failed with output: ERROR \'"/srv/slapgrid/slappart3/srv/runner/software/cc0326f0dcb093f56c01291c300c8481/bin/check-apachedex-result" --apachedex_path "/srv/slapgrid/slappart3/srv/runner/instance/slappart7/srv/monitor/private/apachedex" --status_file /srv/slapgrid/slappart3/srv/runner/instance/slappart7/srv/monitor/private/apachedex.report.json --threshold "70"\' run with failure, output: \'Score too low: 0% - Threshold: 70.0%\\n\''
      ```
      
      See merge request nexedi/slapos.core!344
      e2cebc0c
  12. 12 Nov, 2021 3 commits
  13. 11 Nov, 2021 1 commit
  14. 10 Nov, 2021 3 commits
  15. 08 Nov, 2021 1 commit
  16. 06 Nov, 2021 2 commits
  17. 05 Nov, 2021 2 commits
  18. 04 Nov, 2021 1 commit
  19. 29 Oct, 2021 1 commit
  20. 25 Oct, 2021 1 commit
  21. 23 Oct, 2021 1 commit