Views + Views bulk operations intergration

This is good stuff! Is their interest in including this with Invite module (I think it should) or would the maintainers prefer this be a separate project?

+1 subscribing

Applied patch #489898: The Cancel Link From invite/withdraw Does Not Respect Destination Queries
And then enabled invite-views module at #1

Issues found so far:
1) Pending invites are shown under Accepted views display
2) Pending views display never shows anything
3) => waiting 1 day for Invitation expiry and will report back

+1 subscribing

Hi smk-ka,

Adding views support to Invite module would be really awesome!
I hope to help with testing.

Thanks!

+1 subscribing

I was wondering if anyone has had time to add Views integration? I would love to help with testing!

I'm using #1 with views3, so far so good.

One thing to note - if you are using memcached and you have a memcache bin set up for views, make sure you connect to it and do a flush_all.

It works surprisingly well out of the box. There are coder cleanups, documentation, etc - but at least for me the base module works quite well. Two questions to the Invite module maintainers:

1) Would this be considered for inclusion in the invite module itself, or as a separate module to be enabled on its own (per the current design)?

2) In the event you want it as a separate module, would you want it as part of this module (as a sub-module) or split out into its own standalone project?

I started to wonder why none of my invite paths worked any longer - access denied. So, after a trip through user_access(), index.php, and menu_execute_active_handler, I figured something out. The module comes with a default view called invite which takes over the paths of the invite module. This is enabled by default.

Good idea, one problem: the default access control is set to "access user profiles" while the invite module uses the permission "track invitations". This was a problem for me because I do not allow any users on my site to access user profiles since I use content profile with some other magic to hide core profile. So the end result was a ton of debugging to figure out that this view was causing the permission issue.

Fix #1: modify invite_views.views_default.inc, replace all instances of 'access user profiles' with 'track invitations' to more closely match the core invite module.

Again I'm happy to roll this stuff in as patches, but I'd like to hear answers to my questions first so I know which direction to go.

subscribe, +1

Invite Views integration: http://drupal.org/sandbox/nevergone/1111788
I would apply co-maintainer.

Views integration started: 6.x-invite_views branch.
http://drupal.org/node/1124708#comment-4376174

I am closing this issue, since it's for a Drupal version no longer supported.