Port Storm to Drupal 7 (Now called Project Management)

I was looking for source od D7CX tag, and what it exactly means :). Here it is: http://cyrve.com/d7cx (if someone else wants to know).

And I would like to help you in this effort, it is very important step (or better: leap :) ).

I have installed Drupal 7.x-dev (night build 04.12.2009) and storm-7.x-1.x-dev
Every storm's page has an errors...
What versions should be used to see features of storm?

Thanks for greate module.

+1 Subscribed

- As Storm and Ubercart (hopefully will be easier to integrate come D7?) are pretty much the only modules I use, this port is pretty important to me. I want to switch to D7 as soon as I can

Subscribing...

Subscribing

Subscribing

I am using Project Issue Tracker on D6, but I am considering setting up a brand new D7 site (much easier, although there is still a lot of room for improvement). Since I don not maintain software but publishing project, Storm may be closer to my expectations. Plus, for now, it is the only D7 project tracker, according to this page.

Let me just update on this. Due to the changes in maintainer this has fallen a little bit by the wayside. However, I am quite keen that we still keep to the D7CX pledge of getting a stable D7 release out by the time that Drupal 7.0 is released. The number of critical issues for D7 (113 at this moment) is dropping fast now, so I suspect that we don't have all too long now.

I'm quite busy on other projects at the moment, but in around 3 weeks, I should have time to focus more on Storm.

It may be that some of the Fields API integration has to be put on hold to get an initial release out. Which is a shame, because the plan was to be rid of the attributes module - but that may have to be for now.

Obviously everyone who has subscribed to this issue has an interest in seeing the D7 port come out. Therefore, it would be great if people could comment and commit to helping out on this. As I said, hopefully in about 3 weeks I will have a bit more time to spend on it.

I am very interested. Unfortunately, I cannot contribute any kind of code.

Subscribing...

Just to update this issue, I hope to do a significant amount of work on this during today and tomorrow. I will use separate issues to test patches etc. Please do get involved if you have some time.

subscribing

subscribing

Hi all,

Here is the current status of the D7 port. I have started this several times, but have never had time to get far enough to make it worthwhile.

Unless others chip in with their time, it is unlikely this will be done soon.

Something that would really help is amending the d6 version to utilise other modules such as views. I have listed a few issues in the roadmap for 6.x-1.35.

I look forward to everyone that has subscribed to this issue doing a small bit themselves to help.

I think Storm could be a Feature in Drupal 7. More and more feature modules are coming up on drupal.org. That might make it easier to build Storm for D7? Features for D7 has been sort of ready to use for a couple of weeks now. What do you think?

Features is a topic for a different issue. I have had previous offline discussions about it and have not been persuaded, but tbh I am not up to speed on exactly how it would affect storm.

I think this issue should remain to discuss a direct port of the current drupal 6 version into drupal 7.

subscribe

subscribe

subscribe

Out of curiosity I ran storm.module through coder, other than dumb little changes to the coding standard (like string concatination now requiring spaces on both sides of the ".") most of the issues I see are fairly manageable. The only exception is the DBTNG conversion as hook_db_rewrite_sql is gone in D7 (something I think was a good idea) that means a lot of query re-writing for Storm. Given that Storm uses hook_db_rewrite_sql to enforce all of it's security that means more fun with tests. From what I can tell the best strategy is to move a system where hook_storm_rewrite_where_sql is replaced by hook_query_storm_node_access_alter see http://drupal.org/node/224333#db_rewrite_sql and storm_db_rewrite_sql is dropped altogether.

For example in the stormticket module in lieu of stormtimetracking_storm_rewrite_where_sql($query, $primary_table, $account) it would be stormticket_query_storm_node_access_alter(QueryAlterableInterface $query). I get hook_query_storm_node_access_alter because I'm adding $query->addTag('storm_node_access') to the query object in the sample below from line 901 of storm.module (6.x-2.x-dev branch):

Replace

      $sql  = "SELECT n.nid FROM {node} AS n
        INNER JOIN {stormproject} AS spr
          ON n.vid=spr.vid
        WHERE n.status=1
          AND n.type='stormproject'
          AND spr.organization_nid=%d";
      $sql = stormproject_access_sql($sql);
      $result = db_query(db_rewrite_sql($sql), $organization_nid);
      while ($project = db_fetch_object($result)) {

With

      $query = db_select('node', 'n');
      $spr_alias = $query->join('stormproject', 'spr', 'n.vid=spr.vid');
      $query->fields('n', array('nid'));
      $query
        ->condition("n.status", 1)
        ->condition("n.type", 'stormproject')
        ->condition("{$spr_alias}.organization_nid", $organization_nid);
      $query->addTag('storm_node_access');
      $result = $query->execute();
      // TODO: update stormproject_access_sql
      $sql = stormproject_access_sql($sql);
      while ($project = $result->fetchObject()) {
        $projects[] = $project->nid;
      }

I haven't figured out where the various _access_sql functions and storm_rewrite_sql fit into this plan, but then I only have an hour or two into this and most of that was spent trying to get rid of annoying syntax issues pointed to be coder :)

I have to admit i'm not quite sure I understand the reason for the two sets of functions that re-write the sql for node access purposes.

It seems, and I'm sur eI'm missing something here, that various _access_sql functions and storm_rewrite_sql functions do about the same thing as hook_storm_rewrite_where_sql. I know the resulting SQL is different but what is it that necessitates the two sets of nearly identical functions? ideally there would be a more efficient way to do that.

Subscribing

sub

Getting an error when trying to install the Storm - Organizations module:

FieldException: Attempt to update an instance of a nonexistent field . in field_update_instance() (line 524 of /home/.../public_html/dev/drupal/modules/field/field.crud.inc)

Subscribing

The installation passed w/o any errors, but when attempting to open Storm dashboard the following error message is displayed:

Fatal error: Call to undefined function stormorganization_access() in /var/www/html/cm7/sites/all/modules/storm/storm.module on line 644

Shouldn't be name of this function not "stormorganization_access_sql"?

The site was migrated from Drupal 6.20.

Subscribing

subscribing

Subscribing

Subscribing

Subscribing.

Subscribing

Subscribing

subscribing

Subscribing

subscribing.

subscribing

subscribe

Changing issue title so it doesn't get lost in dashboard

Hi all,

Here is an update on where Storm is currently at, especially considering that people are asking when Storm will be ported to run with Drupal 7 core.

Unfortunately, the number of people who are actually helping out with issues (whether this be to answer questions, ensure full information is available on bug requests, or to code solutions) seems to be decreasing. Furthermore, this is directly impacting the rate of development of Storm.

Currently, my main focus is on getting a few key features (such as full use of the views module) into the 6.x-2.x branch, so that I can start point releases on that branch and make it the recommended version.

Once this is complete, I will move my focus to porting that branch to Drupal 7. However, this will be a significant effort, and I may not have time for it unless Storm users step up and help, either by direct development, sponsorship, or either taking the load of some of the bug fixes and tasks that need to be done outside of the port to Drupal 7.

I am not suggesting any timescale for the port, as it is dependent on when I have time to do so, and how much (if any) support comes from others.

subscribing

subscribe

subscribing

Has any progress been made since May?

Is there any kind of roadmap for the project? I looked in the group, but I didn't see anything.

I'm wondering where you plan to go with the D7 version once you've been able to get it ported and stable. Especially if you are going to work on upgrading the interface to something modern.

I don't think anything changed from the statement made by juliangb in #43.
There should be a stable release of the branch 2.x first, which can be ported later.
In my opinion the drupal 7 version of storm should do a lot with the core fields of d7, but this means a lot of rewrite, maybe to start form scrap...

Not meaning to pester you, but I too am anxious for a Drupal 7 release and would really appreciate a best guess time-frame on when it should be available.
Thanks.

Drupal 7 is working with entities and all recent contributed modules are based on entities.
Porting from D6 makes no sense at all, since storm is not just a one little module but a whole set, working together. The D7 version will need to be a rewrite from scratch, since all containing submodules will be need to based on the recent developments in D7. So +1 for a whole rewrite...but, it will be a lot more flexible in the end.
I have been working with D7 since it came out, and I think about now it is very wise to switch to D7, since the most important modules are fairly stable. And, the whole D7 entity based framework makes it also easier to build.

I would refer everyone who is commenting, to my last comment in #43.

Please think about whether you could help out with Storm. Even if it isn't directly with the port, if we can have more eyes on bugs / necessary tasks, then it will be easier to move towards Drupal 7.

@Yuri: that is not true. The recommended porting procedure is to make minimal changes from the latest 6.x branch, then create a new 7.x-2.x branch to contain the updated 7.x coding. So juliangb's statements are correct and the way to go.

So, if I'd like to help test things, would it be wiser to spend my time on 6.x-2.x, or on 7.x-1.x?

I would recommend spending the time testing 6.x-2.x. We are hoping to make a stable release on this branch soon.

Once the 2.x release is out, we can discuss the best way forward for Storm-like functionality in Drupal 7.

I think now would be a good time to re-ignite this discussion.

For anyone that hasn't followed it closely, the 6.x-2.x branch has now reached betas, and I'm confident that we'll be moving on to a full release fairly soon. Thus, it is time to think about Drupal 7 again.

Before going full steam ahead on porting, I'd like to get views on whether this is the right approach. Are there any other modules that mean Storm is not necessary for Drupal 7? The only similar module that seems to have D7 code is the support module, but this offers only a small part of Storm functionality. Any thoughts?

On the assumption that we will port Storm in it's entirety, here's a proposed plan of action:

1. The 7.x-1.x branch in git is refreshed to mirror the current 6.x-2.x branch. There was a previous effort to port, but since there have been substantial changes to the 6.x branch since then, which I do not want to lose.
2. We adopt a strict policy that changes go into 7.x-1.x prior to 6.x-2.x (akin to Drupal core), even though 7.x-1.x is not yet working. I think we need this to keep momentum going on the port.
3. The port is handled via patches in smaller separate issues. This issue is kept to discuss progress only rather than any code changes. No single person has enough time to do this alone (although I am intending to commit a significant amount of time) - so I am hoping that a significant number of people on this issue chip in. The port is to be done directly, rather than including any feature changes, unless separately discussed.
4. Once we get to that stage, we go through an alpha, beta, rc cycle to ensure that we're releasing a stable version.

I'd welcome any options, and just as importantly, is there anyone that is willing to commit to helping out on this?

Wow, I am really looking forward to this. I have been using this module on D6 for my own projects and will volunteer my support in testing and development. I'm no PHP expert but I have some basic development knowledge in D6, especially theming, and would appreciate the chance to work on something in D7.

I have refreshed the 7.x-1.x branch from 6.x-2.x.

Therefore, it is ready for developers to post patches against. It is not ready for testing or general use.

Hi all,

To give an update on the port:
- I am trying to keep the release notes up to date with which bits of Storm are thought to be working.
- Currently, you'll hopefully find that all modules install without errors, and the Storm basic and Storm organization modules are working (with known bugs).

There are a few things that you can do to help:
1 - Test the 7.x-1.x-dev release.
- Read the release notes, and have a play with the parts that are claimed to be working, and post issues for anything that doesn't.
- Try upgrading a Drupal 6 installation.
- None of this requires coding knowledge!
- Thanks to those doing this already!

2 - Write automated tests.
- Automated tests are one of the best ways of ensuring that everything works, and remains working after changes are made.
- Tests should be (almost) the same for both Drupal 6 and Drupal 7.
- We need people who can extend our tests for Drupal 6. We can then use these as a checklist the Drupal 7 version.
- This requires some basic coding knowledge, but is very easy to learn (and there is good documentation on drupal.org about writing tests).

3 - Help with the full coding
- Give me a shout if you'd like to be involved.

Thanks,

Can you point me to the "good documentation on drupal.org about writing tests". Not sure where to start.

Definitely: http://drupal.org/simpletest-tutorial is for Drupal 6, and is the best place to start.

We already have some tests that check access to pages and creating nodes, but only very simple cases. We could do with some that check other permissions, or run through more specific use cases.

Subscribing

Subscribing

No need to subscribe anymore. There is a Follow link on top of page.

For those following this issue - please be aware of some discussion that happened on the Storm groups on http://groups.drupal.org - http://groups.drupal.org/node/256578 .

There will be some more activity on this port over the next few days - especially if you can help.

As a roughly monthly update to this issue, we've made a lot of progress with Storm for Drupal 7.

I need to also make you aware that Storm will shortly use views for all lists, so please download and enable views when testing.

If you haven't tested in a while, please do try D7 Storm out, and write up any bugs that you find.

tis looking good so far...... no errors reported yet. thx again !!!

Thanks for testing!

But I know there are things that don't work at the moment... so keep testing and creating issues!

Can you please point out and prioritize what you know it's not working ? I can look into some stuff and maybe roll some patches.

If you filter the issues list by 7.x-1.x, those are the bits we're working on.

The priority is probably to move to using views for all of the pages such as storm/organizations , storm/tasks etc., and there'll be some for ensuring all of the views capabilities that we had in D6 are working.

There are also some bits we need in terms of getting the Ajax working on node forms.

All, juliangb did a useful roadmap, you are welcome to contribute, review patches, follow progress at https://drupal.org/node/1862286

Moving this issue to the new pm project, the new name of the Storm modules (for Drupal 7 onwards).

I get this when clicking on the timetracking link on /storm
PHP Fatal error: Call to undefined function db_rewrite_sql() in stormtimetracking/stormtimetracking.admin.inc on line 170

For the sake of the many people following this issue, I will not respond to any feature requests / bug reports on this issue.

Please check the issues queue and make a new issue if necessary.

Thank you for your understanding.

All, here is the direct link to create a new issue for the Drupal 7 version http://drupal.org/node/add/project-issue/pm
For Drupal 6 version https://drupal.org/node/add/project-issue/storm

By my accounting, I believe the PM module is now ready for alpha release testing.

Once the PMMigration module (#1960726: Migration: Rename storm node_types, #1914630: Migration: Rename variables and #1909448: Migration: Refresh icons location) is completed, the work will be focused on "neatening this up" (see #1862286: Meta: Development Roadmap - 7.x-2.x version .

When is a "port" considered completed? Alpha, Beta, RC or Stable Release?

It is very exciting after the long wait and a lot of hard work that we're finally here.

I suggest we mark this issue as fixed, when we release alpha (definition of alpha: the release will work, but needs caution against bugs and the codebase is open to a lot of change), but also comment here to notify all of the followers when we reach the other milestones.

I imagine that each person following will have their own idea of when the release is ready to use.

The alpha 1 release of Project Management will be created on 1st July 2013.

#2029129: Alpha 1 release.

I'm pleased to announce that I have just created the alpha 1 release of Project Management.

Whilst there may still be bugs, and some aspects of functionality will change, this marks the completion of the "port to Drupal 7".

The release works and is good to try out, although you should note that it is still in alpha (as I said, may be bugs, some functionality will change) - which means you should use discretion when installing on production systems.