Support for views

Subscribe.

Subscribe

It does not support views (yet?). I'd love to spend some time on the module but haven't got any :(

(I'm looking for a co-maintainer)

@Damian and @subscribers can you please give one or two use cases for views & annotate you would like to create? If you can attach an exported view and explain what you want to see from annotate would be awesome.

When you create a "node" view + "Row style: Node", the annotations are visible just fine. Doesn't seem a problem to me.

I want to create a page which shows all the annotations of a user in a table. In a single row it must show at least (a part of) the text of the annotation and the page where the annotation is located. Should this be possible with what you described?

I want to create a page which shows all the annotations of a user in a table.

Did you look at http://example.com/user/[uid]/annotations? Can you explain what you would like to change on this page?

Maybe it's because a colleague did some changes, but that page displays the user information. It isn't showing any annotation information.
Is there also a block available for displaying your annotations? I want to create this with views aswell.

I agree; I think it's just that it adds flexibility to the display of annotations someone has left.

Some use-cases for views support I can think of

Listing of the most recent public annotations (as a block and page)

Listing of the most recent annotations someone has made (as a block)

It also could provide a good way of listing all annotations that have been made for admin users

My use-cases are from an instructional perspective as I'm looking at possibly adding this module into my elms stack.

Here it is.

A first version of views for annotate.
The patch makes it possible to include annotate fields in "node" as wel as in "user" views.

I uploaded 2 patch files: 1 against head, the other against the stable 6.x-1.1 release.

I tested the patch against views 2.12 but i assume it will work against views 3.x too.

Subscribe

@franskuipers: Thanks for the patch. I'll try it today or tomorrow and report back :)!

I'm trying to get this working, but I keep getting the following:

File to patch: annotate.module
patching file annotate.module
Hunk #1 succeeded at 668 with fuzz 2 (offset -12 lines).
(Stripping trailing CRs from patch.)
patching file annotate.views.inc
(Stripping trailing CRs from patch.)
patching file annotate_handler_field_note.inc
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 189:

Could be useful to mention that I'm using the 1.1 patch, as I am using Annotate 1.1..

@jeffreyvddb a few questions:
* are you sure you use an unchanged annotate-6.x-1.1 version (I don't understand the Hunk #1 succeeded at 668 with fuzz 2 (offset -12 lines).)
* Apparently you work on windows (Stripping trailing CRs from patch.). Did you read this: Apply patches on Windows?

I tested the patch on a clean downloaded annotate-6.x-1.1 and it works (on linux).

From irc I got

dereine
: ngnp: so you have something like the node editor in the global context?
[16:16] dereine: for example you only show the view on nodes?
[16:16] dereine: There is hook_views_query_substitutions
[16:16] dereine: see node_views_query_substitutions as example

[16:31]
merlinofchaos
: ngnp: What's the schema for the annotations table look like?

ngnp
[16:32] : http://drupalcode.org/viewvc/drupal/contributions/modules/annotate/annot...
[16:32] ngnp: visibility is puzzling me because it's related to the node author for value 1
[16:33]
merlinofchaos
: ngnp: Ok, you probably want to do this mostly with relationships, the same way flag module does.
[16:33] merlinofchaos: ngnp: This is kind of an advanced use of Views, and it's also super powerful.
[16:33]
dereine
: ngnp: and then if you want to filter by all annotations you add the relationship to user, and use the user: current filter. That's it
[16:34]
ngnp
: Thanks ... I check how flag module did it.

[16:35]
merlinofchaos
: ngnp: At a high level, your schema is doing the same thing flag.module does, which is that it creates a relationship between a node and a user. flag.module is just bookmarking it, whereas you're adding extra data along with it. But if you draw it on paper, it's the same with a couple more fields.

What the patch lacks is annotate filtering based on de current user and the node editor.

Say you want all your annotations: that needs a filter on CURRENT_USER

Say you want all annotations targeting you as a node editor: that needs a filter on all annotations with visibility author related to nodes edited by CURRENT USER

- A.uid == CURRENT_USER => my annotations

- A.uid == CURRENT_USER and visibility == private or visibity == editor => my private or editor visibile annotations

- N.uid == CURRENT_USER and N.nid == A.nid and A.visibility == author => annotations targeting me as node editor

The reply I posted was a changed version indeed, but on an unchanged version it still isn't working. I get the following:

File to patch: annotate.module
patching file annotate.module
(Stripping trailing CRs from patch.)
patching file annotate.views.inc
(Stripping trailing CRs from patch.)
patching file annotate_handler_field_note.inc
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 189:

And I still don't have the possibility to add annotation fields to a view.

I'm using WinSCP and PuTTy to apply the patch. I'm using '$ patch -p1 < {/path/to/patch/file}'. Is this correct?

Discussing with Frans about the need of the views concept of ***CURRENT_USER*** for filtering annotation I ended with the following sql expressing the filters a little more explicit.

SELECT * FROM (

SELECT "PRI" as vis, n.title, a.*
  FROM annotations a INNER JOIN node n ON a.nid = n.nid
 WHERE a.visibility = 0 AND a.uid = 6 # CURRENT_USER

UNION

SELECT "EDI", n.title, a.*
  FROM annotations a INNER JOIN node n ON a.nid = n.nid
 WHERE a.visibility = 1 AND n.uid = 6 # CURRENT_USER

UNION

SELECT "COL", n.title, a.*
  FROM annotations a INNER JOIN node n ON a.nid = n.nid
 WHERE a.visibility = 2 AND a.nid IN (SELECT nid FROM annotations WHERE visibility = 2 AND uid = 6 /* CURRENT_USER */)

UNION

SELECT "OTH", n.title, a.*
  FROM annotations a INNER JOIN node n ON a.nid = n.nid
 WHERE a.visibility = 3

) AS T

ORDER BY title

I have build in the visibility enforcement. I am not really happy with the way I did it.

But maybe you can test it if it works as intended.

So the question is how we can add something like this JOIN to the query definition:
WHERE ( annotations.visibility =2 OR ( node_annotations.uid =1 AND annotations.visibility =1 ) )

Could it be something like this: http://drupal.org/node/933504#comment-3557150 ?

I think this patch is pretty complete. It obeys the visibility of the annotation as it does in the annotate module.

Also added a default Block view with displays on node context (http://example.com/node/%)

version change

A git version of the patch (and some code cleanup).

@clemens you can apply patch with: $ git am annotate-916922-views-4.patch
It applies the patch & commit it with my commit message :)

Removed some leftovers from flag module in default view.

Here are some notes about the attached patch.

- I refactored the visibility filter option: the list of options is provided by the annotate.module
- The field visibility was missing: re-added from one of franskuipers previous patches
- I refactored the block view and renamed it: annotate_recent
- I added a view page node/%/annotate: annotate_by_node

After #581518: Move configuration to content type is fixed and this issue is committed I'm puzzled what to do with the views.

- path node/%/annotations (provided by annotate.module) should be replaced by the provided view node/%/annotate
- path user/%/annotations for the same reasons

In patch #26 I have disabled the views but enabling the node/%/annotate view is a little useless now. This would duplicate the node/%/annotations tab.

I guess I can only delete the module provided pages node/%/annotations and user/%/annotations in a 6.x-2.x release right?

What do you think?

Committed to 6.x-1.x-dev

#581518: Move configuration to content type is still needed to create a stable release.