List pages to be default views

This seems like a way to go. I think it's pretty assumed that most sites running drupal use views or will need to at some point, so the dependency on views isn't a hassle.

The only thing I am worried about is having too many default views - I know I personally dislike modules which bring in 10 of their own views and clutter my views page even more. How many views are we thinking of, or will one or two views with many displays cut it?

I think we need to figure out a way to drill down "Organization, Projects, Task, Ticket' into a view, have a view for knowledge base, a view for invoices, a view for notes. Any other sections I am missing?

I would say max 5 views. The Calender module for example, comes with a default view, which has displays in it for YEAR, MONTH, WEEK, DAY, among many other items. Combining Organization, Projects, Task, Tickets into a view somehow, would be best.

The view could be multiple displays,
Say the views page(s) are located at storm/*
Organization page would then be : storm/%/ (ORG ID or TITLE)
Project page would then be : storm/%/% (ORG ID, PROJECT ID)
Task page would then be : storm/%/%/% (ORG ID, PROJECT ID,TASK ID)
etc...
Where each display holds the fields for that content type.

What do you think of this method?

I would love to - if it can wait - I'm going on vacation for 6 weeks in 3 days (ahhh, the good life) but will definitely play around with it when I get back.

Hello there, I think this will be a HUGE MAJOR improvement on Storm!

I just installed storm 2 weeks ago and I'm currently busy making 3 panels and 2 views both containing ~5 blocks for the site.

I very much like things JGonzalez stated in #3, think he forgot persons/teams/timetrackings.

I think this will be a major time investment also, customizing the views and making it all work.

I have no experience coding things for views though I can help test things and think about the design!

Greetings Wappie

sub

yep, this is a must for this module, subscribing

I don't know if there was any progress on this topic, but because of #1153672: Missing Date API for Views i needed to create some views to test. So i decided to create Views, which maybe helpful here.
I attached my exported views.

Some thoughts and something like a todo list of things thats missing at the moment. Maybe someone have a good idea to one of this points. I haven't done much with implementing new things for views.

• when we want as few Views as possible, then we will overwrite much of the default view in each display
• for the arguments and to create manually a link, we need the nid of organization, project, task, ticket, persons, ...
• the organization, project, task and ticket, person, ... titles should be linkable like the node title -> works, using relations and node_title field
• complete permission handling is missing for now, because at the moment, i have no idea how to implement this, maybe an extra permission handling (so we can select it at the permission properties in the display) - Permission at the moment is 'Storm xxx: View all' -> Views does it automaticly
• Icon replacement of some fields, like status, category,... - replace this in the theme? -> #902962: Handler for attributes icons in views
• relation which gets the stormperson of the nodes author - for timetrackings
• for the invoices and expenses something like a sum row as last row would be nice

The currently used urls:
1. View (storm)

• storm/organization -> list all organizations (i cut the s in the url on purpose, to not overwrite any existing urls at the moment)
• storm/% -> list all project of the organization, first argument is the organization title (this should be id, but we need to add this)
• storm/%/% -> list all tasks of the project, second argument is project title
• storm/%/%/% -> list all tickets of the task, third argument is task title
• storm-timetracking/%/%/%/% -> list timetrackings, arguments like above, but optional; fourth argument is ticket title

2. View (storm_misc)

• storm-invoice/%/% -> lists invoices (optionally organization title, project title)
• storm-expenses/%/%/%/% -> lists expenses (optionally organization title, project title, task title, ticket title)
• storm-person/% -> lists people (optionally organization title)

the storm-xyz is a workaround, otherwise the project list would try to find a project with name xyz. For normal menu entries this works, but not for entries created by the views module. this only happesn, if the view has additional arguments. storm/organization works.

It is a lot of work and i hope, with this i helped a little bit.

Coming from #1178640: Views integration, Views relationships, and Views arguments, subscribing

After I created the patch to #902962: Handler for attributes icons in views, it reminds me of this issue.

I think the next big steps would be the permission handling and that it would be possible to add links to project, organization, task and tickets. For the linking we need another handler, It should extend views_handler_field_node_link and only overwrite the render, that it displays the text instead of "view".
For the permission i do not have a clever idea right now.
Maybe a filter field, which the user have to add manually to his view, so the admin can decide, if he want the filtering by access or not. If we want to do this automatically, we have to add for each field a handler, where we can manipulate the query. Or we implement hook_views_query_alter or hook_views_pre_execute, but then we have to check, which fields are getting pulled from the database and if there is a storm field present, we add the access_sql.
Any suggestions - manual filter field vs automatic access control by storm?

No there aren't any issues for this at the moment, but would make sense to add tickets.

Okay the permission handling seems to be working. I wonder why, because i didn't see anything which handles this in the code for views and expected this doesn't work. It must be magic by views ;) (Can someone please tell me why? :P )

But the second task still exists. If you have project view, then you can't link the organization, assigned or project manager, its plain text. And you can't get the organization_nid, assigned_nid, project_manager_nid to manual rewrite the output, because only the organization_title, ... is a field. But it would be a common use-case that you link to organization and not only output the title.

I didn't test this right now, but i think with relations views should add joins to the query, which we doesn't need there and would slow down the query. Otherwise maybe views notice that it needs no fields from it and doesn't add the join or it will be cut of by the mysql pre processor.
I will test this and maybe will add a link handler, when some of my concerns are proven right.

You are right, with relations this works great. I updated my comment #11.
It seems we have a decent views support now.

I will have a look into the PK thing and will create a new issue, if i found something, because it would be related not only to views.

Before i create issues for the other points, i think here is the right place to discuss views related stuff first.

Next two task would be (if there issn't a solution, which i didn't think of, like the last time):
We have a relation stormperson -> Drupal User, but no relation Drupal User -> stormperson. I think this would be nice, because if you have stormperson enabled, you maybe only want to link to the person not the user. Especially for timetrackings, where you can't link the node author to the stormperson.

The other task would be any good idea, how we maybe add a summary under the view, like in the invoice or timetracking list right now, where the values get added up.