1. 02 Dec, 2015 2 commits
  2. 01 Dec, 2015 2 commits
  3. 30 Nov, 2015 7 commits
  4. 27 Nov, 2015 6 commits
  5. 26 Nov, 2015 8 commits
  6. 25 Nov, 2015 3 commits
  7. 24 Nov, 2015 5 commits
    • Sean Hammond's avatar
      Revert "Hide threads with missing roots" · 1f5199a5
      Sean Hammond authored
      This reverts commit 5a5b4e345c050a71e619fb5732426b2306f29e64.
      1f5199a5
    • Sean Hammond's avatar
      Make returning replies separately optional · 0ea42019
      Sean Hammond authored
      Add a new, undocumented separate_replies=True option to the search API.
      
      If separate_replies=True option is _not_ given to the search API, then
      it reverts to its previous behaviour: _do_ include replies in the "rows"
      list returned. This is the same behaviour that the search API had befor:
      it returns both top-level annotations and replies in the one "rows"
      list, but without any guarantee that if some annotations/replies from a
      given thread are in the list then all annotations/replies from that
      thread will be in it.
      
      If separate_replies=True _is_ given then the API follows the new
      behaviour: "rows" contains top-level annotations only, and a separate
      "replies" list containing all replies to the annotations in rows is also
      inserted into the result.
      0ea42019
    • Sean Hammond's avatar
      Make loadAnnotations accept separate annotations and replies arrays · 82d25138
      Sean Hammond authored
      Do the concatenating of these loadAnnotations() instead of in multiple
      places that call it.
      82d25138
    • Sean Hammond's avatar
      Change the search API to search top-level annotations · 1b4a6bae
      Sean Hammond authored
      Fixes #1916.
      
      Get rid of "Message not found" messages on the /stream page.
      
      Problem:
      
      The stream requests the most recent n annotations from the
      search API, but what it actually gets is the most recent n annotations
      _and replies_. In some cases a reply may be in this set while the parent
      annotation that it is a reply to is not.  When that happens, the frontend
      just displays "Message not found" in place of this thread (parent
      annotation and replies).
      
      Solution:
      
      Change the semantics of the search API: only return the top-level
      annotations (not reply annotations) in "rows". Replies are always
      filtered out from the Elasticsearch query results. "total" (and "limit" and
      "offset") only apply to these top-level annotations.
      
      Additionally, always do a second Elasticsearch query to get _all_ reply
      annotations to the matching top-level annotations, and return these in a
      new "replies" key in the API response.
      
      This means that whenever the frontend calls the search API, it always
      gets back all of the replies to all of the annotations that it gets, so
      it always has the complete threads and feeds them all into the threading
      code, which can safely assume that it has the complete threads and no
      longer produces any "Message not found" messages.
      1b4a6bae
    • Sean Hammond's avatar
      Enable highlights by default everywhere · faf39d80
      Sean Hammond authored
      Enable highlights by default in the Chrome extension, bookmarklet and embed.
      
      They were already enabled by default in the Chrome extension and
      bookmarklet so this only changes the embed.
      
      Highlights are turned on by default in annotator/host.coffee if no
      showHighlights option is found.
      
      The extension and bookmarklet no longer need to set showHighlights: true as
      this is now the default. The embed (which was not setting showHighlights: true
      and so was getting the default setting of false) will now get the new default
      setting of true.
      
      For people embedding h into their own pages, they can turn off highlights by
      default by including:
      
          <script>
            window.hypothesisConfig=function(){return{showHighlights:false}};
          </script>
      faf39d80
  8. 23 Nov, 2015 3 commits
  9. 20 Nov, 2015 3 commits
  10. 19 Nov, 2015 1 commit
    • Sean Hammond's avatar
      Keep permissions of new annotations in sync when changing group · 4ff2c56f
      Sean Hammond authored
      Keep the permissions of new annotations in sync with the group, when
      changing the focused group.
      
      This fixes an issue where a new (not yet saved to server) shared
      annotation in group Foo would become a private annotation if you changed
      the focused group to Bar.
      
      The issue is that model/@annotation.group gets changed to Foo, but
      model/@annotation.permissions still contains a permissions object with
      group Bar's ID in it, and as a result the permissions service thinks
      that it is a private annotation.
      
      The fix is to update both .group and .permissions when the focused group
      changes, and to update the drafts service _after_ doing this not before
      (otherwise a copy of the annotation containing the previous group's ID
      gets saved to the drafts service, and then later gets read from the
      drafts service and overwrites the correct data).
      
      Fixes #2713.
      4ff2c56f