Expose Storm fields to Views

Hi you all.

This is my first attempt to expose a field to Views, concretely the Organization name on the stormtimetrack.module. I would like to create a calendar view to my timetracks. I've tried to use as a model the stormorganization.views.inc file. I guess that if I succed there will be very easy to add other fields and have support on views of storm fields.

The point is that I've added the attached file to the stormtimetrack folder but I don't know how to tell Views to consider those arrays. Which is the next step? Is that file correct? Any help?

PS.: I've added to the file a .txt because the file attachment system doesn't allow to upload files with the .inc extension. Rename the file to stormtimetracking.views.inc

I finally realized that I was missing to declare where the file had to allow views to find it. It only requires to add to the stormtimetracking.module the function (it could be the very first function):

<?php
function stormtimetracking_init() {
  // ensure we are not serving a cached page
  if (function_exists('drupal_set_content')) {
    if (module_exists('views')) {
      include_once(drupal_get_path('module', 'stormtimetracking') .'/stormtimetracking.views.inc');
    }
  }
}
?>

I took that function from stormorganization.module, changed the names and now it works smoothly. I'm able to call the organization name related to a timetrack from views. Now I got a calendar views where I see the moonthly result of timetracks seen the name (node) or basis description and the organization it´s related. Maybe now I'll add the number of hours.

Beware that if you add that code to your testing environment (just in case anyone would like to try to add views support to Storm) that you have to desactivate the module on the Module page in the Admin area, and afterwards reactivate it again, otherwise Views does not list the new fields or arguments.

It means that is far easier than I thought to add views support to all the Storm modules... :-)

This is the code inside "stormtimetracking.views.inc":

<?php
// $Id

function stormtimetracking_views_tables() {
  $tables['stormtimetracking'] = array(
    'name' => 'stormtimetracking',
    'join' => array(
      'left' => array(
        'table' => 'node',
        'field' => 'vid'
      ),
      'right' => array(
        'field' => 'vid'
      ),
    ),
    'fields' => array(
      'organization_title' => array(
        'name' => t('Storm Timetracking: Organization'),
        'sortable' => true,
      ),
    ),
    'sorts' => array(
      'organization_title' => array(
        'name' => t('Storm Timetracking: Organization')),
    ),
    'filters' => array(
      'organization_title' => array(
        'name' => t('Storm Timetracking: Organization'),
        'operator' => 'views_handler_operator_like',
        'handler' => 'views_handler_filter_like',
      ),
    ),
  );
  return $tables;
}

?>

BTW, I've troubles to add the same kind to views support to stormticket.module. I've lost a long time because my new stormticket_init() function was breaking my site, untill I realized that this module already had that function some lines below. I then just added the lines:

    if (module_exists('views')) {
      include_once(drupal_get_path('module', 'stormticket') .'/stormticket.views.inc');
    }

to that function.

Nektir, beware on #8, what you have seen on http://drupal.org/node/325363 is a completely different thing, one function is related to "view" and the other to "viewS" :-)

What you ask on #7 is exactly what is explained on #4 and adding on the module code what is explained in #2.

What you have seen on #8 is related to how to display some storm data on modules that still don't display the node with the Storm fields (as stormticket and many others).

Sorry if my explanations are not clear :-(

Please, could you provide a patch in diff format.
A quick guide is here:
http://stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html

Hi, I'm sorry I work on Windows and I've found an open source diff tool but I'm not sure if the results are the same as the patches I usually see on drupal.org. I'll try to investigate a bit more.

All in all the two pieces of code I've proposed are:

• an independent new file on #4, you can copy the whole php code and save it on the same folder with the name provided
• a complete new function on #2 for stormtimetracking.module, so you can copy it inside your module code, since it's not having other side effects, it simply looks for the previosly commented file

I use cgwin for linux compatibility:
http://cygwin.com/
also the win32 port should be ok:
http://gnuwin32.sourceforge.net/packages/diffutils.htm
and
http://gnuwin32.sourceforge.net/packages/patch.htm

Attention Roberto, Jordi, etc:

We have won a contract to do sponsored development of STORM + Views to expose all STORM fields to the views module. If all agree, I request that this issue be assigned to higherform for further work.

Thanks for getting the ball rolling, though, Jordi, and of course we will welcome your input, expertise, continued work, etc.

Roberto -
Have you started on this feature at all? Any technical hurdles, obstacles, or other problems we should be aware of?

Hi higherform.

>Have you started on this feature at all?
I started doing something for the Storm for Drupal 5, but only some fields for organization.

>Any technical hurdles, obstacles, or other problems we should be aware of?
I didn't investigate views2 for Drupal 6.

On which version will you work ?

Many thanks, Roberto.

Very good news, I was planning to do it, but if someone is sponsoring this is great because I'll be able to look on a new area :-)

My only concern is that exposing A-L-L-storm-fields to views is going to make things difficult on Views, just because the fields selection on views is with a simple pop up which does not make things easy, and it will become kilometric!! 8-)

But, well, every tool has its own constrictions.

Jordi -

Good point about number of fields showing up in D5 views.... we were aiming at D6/views2, which is a more AJAX categorical select. We will try to bake in "expose to views" controls in module config, but may not have time for that.

Can I recommend tackling either the task/ticket assignment system, or the completed tasks/tickets -> invoice items functions, as I think those will save the most time for the most number of people, but I could be wrong. We have already worked up a custom content type / views set / etc for our own assignments, so I can tell you what has been working vs not, if you take that on.

Roberto -

The site will be D6+views2 ... so we will aim dev at that, and leave it to your expertise to backport to D5+views2 / or views1....?

Client's accountant neglected to send a check so the project is on hold til received (maybe a week or so). In the meantime, I wanted to ask the community about the following issue:

Though Jordi did blaze the trail for integrating with views by exposing the fields directly, I was wondering if there is more perceived usefulness in exposing Organization, Project, Task, etc as Taxonomy Vocabularies instead. The reason why I ask is because there is already Taxonomy fields, filtering, etc in Views, so we would indirectly gain all of that as well. However, exposing to taxonomy means we open up the entire range of taxonomy modules (menu autocreate, archive by terms, faceted search, hierarchical select, etc.) to work on STORM data. We would probably still expose the other "non container" STORM fields (Name, Country, etc) to views the way Jordi did above.

Let me know whatever pros and cons you can think of, besides the obvious having to start from square 1 on the exposure process.

I would go the views way IMHO, since views-cck-worflowng-pathauto-og-... are the way to go. I always have the doubt to tag nodes by taxonomy or by cck-node-reference, and despite taxonomies are easier sometimes lack the depth of nodes powerful handling on views.

My 2 cents :-)

re #18: I'd like to use Taxonomy.

It seems a logical framework for categories, and would allow you to re-order and create a hierarchy of tasks by dragging them up & down a page – much easier than entering step numbers and weights which seems to be the only way to order them at present (see http://drupal.org/node/333064).

JordiTR
Can you post your stormticket.views.inc file here?
Thanks.

Here you are:

<?php
function stormticket_views_tables() {
  $tables['stormticket'] = array(
    'name' => 'stormticket',
    'join' => array(
      'left' => array(
        'table' => 'node',
        'field' => 'vid'
      ),
      'right' => array(
        'field' => 'vid'
      ),
    ),
    'fields' => array(
      'organization_title' => array(
        'name' => t('Storm Ticket: Organization'),
        'sortable' => true,
      ),
    ),
    'sorts' => array(
      'organization_title' => array(
        'name' => t('Storm Ticket: Organization')),
    ),
    'filters' => array(
      'organization_title' => array(
        'name' => t('Storm Ticket: Organization'),
        'operator' => 'views_handler_operator_like',
        'handler' => 'views_handler_filter_like',
      ),
    ),
  );
  return $tables;
}
?>

Put all that inside a file called "stormticket.views.inc" and don't forget to upgrade "stormticket.module" as commented on #2. On that case I've just added that field because I don't need to expose more fields to views on the ticket management.

Old issue title restored.

This is a starting point for Views2 support:

Create a module/storm/stormticket/stormticket.views.inc file with this code

function stormticket_views_data() {
  $data['stormticket']['table']['group']  = 'Storm';
  $data['stormticket']['table']['join'] = array(
    'node' => array(
      'left_field' => 'nid',
      'field' => 'nid',
    ),
  );

  $data['stormticket']['ticketstatus'] = array(
    'title' => 'status', // The item it appears as on the UI,
    'help' => 'Ticket Status',
    'field' => array(
      'click sortable' => TRUE,
     ),
    'filter' => array(
      'handler' => 'views_handler_filter_string',
    ),
    'sort' => array(
      'handler' => 'views_handler_sort',
    ),
  );
  return $data;
}

Add this code at the end of module/storm/stormticket/stormticket.module

function stormticket_views_api() {
  return array(
    'api' => 2,
  );
}

Empty views cache (views->tools).

It exposes the ticket status as field and text filter (next step could be to filter by storm status attributes).

This patch exports all ticket fileds and allows to filter them by stormattributes.
It adds a global stormattribute which allows developers to build attribute filters also for other storm objects (timetracking,etc).
Datebegin,dateened have to be tested.
Be sure to purge views cache before use it.

@jorditr and @samuelet thanks for the work. i am getting ready to evaluate Storm for some projects and will test out #25 patch when I have a chance; hopefully in the next few weeks.

@higherform do you have an update on your sponsored dev work? views support is going to be key for my projects i think.

Thanks,
Coby

At #368597: Expose Organization Fields to Views filter, we're talking about merging into this issue, but that would mean an increase in scope warranting a rename such as "Expose Content Type Filter Fields to Views". They are very similar, but I don't want to hijack progress on this issue as you guys have clearly been working on it and making good progress.

Could you share your opinion on this question at #368597: Expose Organization Fields to Views filter so as not to clutter this area? I hate to see good progress hijacked by these sorts of things. :-)

@cglusky, have you had a chance to test the patch in #25?

@flickerfly, sorry have not tried patch yet. We are looking at ways to achieve similar functionality without storm - OG, user relationships, cck, views type of architecture. Storm seems to be a very good module, and could possibly be great if it had better Views support. But we were looking at it for a use case that is for sure on the edge, so think it may be better to come at it from different direction.

All that said, we are keeping an eye on Storm so if I test I will report back.

R,
Coby

Has anyone tested this...?

Don't be afraid to test this patch yourself :-)
It affects only the views module behaviour and does not change any drupal data.
Also you can revert to the previous state i any moment (you could need only to purge views cache with the admin->performance option).

#25 looks like it could be quite a quick but beneficial win for the module, BUT: i'd like to see a few people report test results. @flickerfly, @cglusty, @asak...?

Just tested the patch at #25 against views 6.x-2.5 and STORM 6.x-1.21 using D6.10 - all seems well. haven't done much testing but creating, filtering and displaying a view of tickets works well.

Issue #1: we now loose the icons.. which is a shame.. i guess this could be done easily within views and will check it out.. but it would be cool to have the module supply a "Status (as icons)" field for display (in addition to "Status (as text)" for filtering possibly).

Issue #2: we loose the links to the Project and Organization - they can be displayed, but not as links.

I think that's it for now...

Views integration is at the top of my priorities for STORM... it will make everything much more intuitive... keep 'em coming ;)

Thanks @asak. In general be aware that i'd be committing patches against the dev branch so that is the one to test against, but the dev is pretty much the same as 1.21 at the moment.

Re the issues, it seems to me that these wouldn't be show stoppers in the sense that having some views integration would be better than not, but would be nice if anyone can see a way to solve them too!

100% agree!

samuelet, thanks for the great patch in #25!

one note for other newbs trying this, i had to patch from modules directory, not main drupal path.

one question regarding views functionality exposed via this patch:
i have access now to all fields for display, but cannot add 'project' or 'task' fields as filters. this is critical to me to allow filtering all tickets by their respective projects and tasks. do i need to enable these node types as well, or should these be accessible via the patch to stormticket implemented in #25? any help on this would be much appreciated.

thanks!

I've just marked #368597: Expose Organization Fields to Views filter as a duplicate of this issue so that views integration comments can all be in one place. Hence the title has become a little more generic too.

My intention is that this will go into Storm within the next week or so depending on my time constraints, initially in the -dev release.

http://drupal.org/cvs?commit=208656
http://drupal.org/cvs?commit=208658

Committed with a few changes.
- The attribute handler I have put in the Storm Attribute folder
- The storm ticket views handler i have put in the Storm Ticket folder

HOWEVER - On my own testing of this, although I have had some problems with the views generated. I applied it on the demo site (running up to date -dev), and although all the fields were available etc, the view generated only showed one ticket, with blank lines for the others.

I thought that it would be best to get the code in as it shouldn't cause problems for other areas and this will give a basis for the future code - but the views support at the moment should be seen as experimental. I'll look at it a bit further in due course.

Magnity,
stormattribute_attributes_bydomain function was changed after #25.
The provided patch fixes it and has to be applied after #37.

Thanks for the patch @samuelet - but it doesn't seem to fix the problem! (caches cleared etc.)

Uhm, i'm using last drupal,views and storm modules and it seems to work correctly.
What's your view query output?

Query output:

SELECT node.nid AS nid,
stormticket.ticketcategory AS stormticket_ticketcategory,
stormticket.datebegin AS stormticket_datebegin,
stormticket.dateend AS stormticket_dateend,
stormticket.organization_title AS stormticket_organization_title,
stormticket.ticketpriority AS stormticket_ticketpriority,
stormticket.project_title AS stormticket_project_title,
stormticket.ticketstatus AS stormticket_ticketstatus,
stormticket.task_title AS stormticket_task_title
FROM STORMnode node
LEFT JOIN STORMstormticket stormticket ON node.nid = stormticket.nid

The view can be seen at http://storm.beta-web.co.uk/views/storm_test (EDIT: corrected link)

I guess because you simply did not create a "Node type = Ticket" filter.
The views support by itself does not filter by storm objects (tickets, projects,etc..), but by storm attributes (with the stormattribute_attributes_bydomain function).
So, in your view, you get, together with ticktes, also projects, people , etc storm nodes, whose ticket attributes are (correctly) empty.
To test it, try to add the "node: title" activating also the "Link this field to its node" option.

Ah yes - I can't believe I didn't spot that. In which case also, i'm not sure that the patch in #38 is required?

An additional note - I started exposing the organizational fields - http://drupal.org/cvs?commit=209026 - although this isn't complete yet.

Organization done - http://drupal.org/cvs?commit=209584
Person done - http://drupal.org/cvs?commit=209602

At the moment the fields are being added in a fairly "rough and ready" way - and my intention is to expose all of Storm's fields like this first, and then work on enhancing what you can do with them in due course - and after people have been able to test it all out.

Done since last update:
Knowledgebase (http://drupal.org/cvs?commit=210526)
Project (http://drupal.org/cvs?commit=211008)
Task (http://drupal.org/cvs?commit=211180)

Overall:
Done: Ticket, Organization, Person, Knowledgebase, Projects, Task,
To do: Timetrackings, Notes, Invoices, Invoice items, and Expenses.

Done since last update:
Timetracking (http://drupal.org/cvs?commit=211984)
Note (http://drupal.org/cvs?commit=211988)

Overall:
Done: Ticket, Organization, Person, Knowledgebase, Projects, Task, Timetrackings, Notes,
To do: Invoices, Invoice items, and Expenses.

Expense: http://drupal.org/cvs?commit=212520
Invoice: http://drupal.org/cvs?commit=212562
Invoiceitem: http://drupal.org/cvs?commit=212566

This completes exposing Storm fields to views (finally!)... please do have a play around with it. The -dev version will have these all from midnight.

If any bugs are found, or extra features needed, please open a new issue - I see this one as simply exposing the fields (hence fixed), and finetuning is best done using smaller individual issues.

Thank you magnity - i'll test this with joy.

i created a separate display of the project list showing only the date field, organization field, and status field. my problem is all users under the same role can view the lists of project items not assigned to them. i want that they can only see the projects assigned to them, not all of them. any tips?