Storm user on this particular site since 6.x-1.9 or so, several upgrades since then.

Upgraded to 6.x-1.24 successfully. Had the following setup:

User UC belonged to Organization OC and could view, ticket for, and see invoices for all project (lets call them PC, PF, and PM, etc) in org OC (as desired)
attempted to allow user UM to ticket to project PM only. ended up with user UC able to see _only_ project PM. I *thought* I had that situation fixed but possibly not before upgrading to 6.x-1.27...

upgraded to 6.x-1.27 a couple of days ago, and ended up with:
- user 1 able to see all organizations, projects, etc. and everything is as expected
- all users > 1 unable to see any organizations, projects, or tickets in storm dashboards (even with no filtering) or on storm dropdowns
- almost all projects had begin and end dates in 1969 or 2038 (sql timestamp of negative, zero, or int(11) maximum value.

tried the following fixes:
- checked role permissions, all were as previously set and as expected, including:
- Storm project: access
- Storm project: view of user organization
- etc.
- checked to be sure correct users had correct roles
- used phpmyadmin sql queries to set all stormproject.datebegin and dateend to something reasonable: no effect
- removed duplicate vid rows for each stormorganization: no effect
- removed duplicate vid rows for each stormperson: users can now see belonged organizations and invoices of belonged organizations
- removed duplicate vid rows for *some* stormprojects: no effect
- set stormproject: view if assigned, then created a team TC, added user UC, set "assigned to" for projects PC, PM, etc to team TC: no effect
- set stormproject: view if project manager, and then set project manager for PC, PM, etc. to user UC's people entry: no effect

odd thing is when masquerading as user UC I can view the project if I type in site.com/node/123 for the project's node...

Tired of grasping at straws, wanted to ask for you all for ideas / feedback, before I start adding copious "watchdog()" debugging output to the module to watch what is happening...

I am also having an issue similar to http://drupal.org/node/327219, however I uninstalled workflow around Storm 6.x-1.12 or so.

Comments

higherform’s picture

higherform commented
Priority: Normal » Critical

Upgrading this to critical per definitions in: http://drupal.org/node/45111 ... users cannot accurately ticket without being able to select the project...

Magnity’s picture

Magnity commented

A few questions:

Do you have a backup of any previous versions of your site?

Are you using revisions?

Do you have any other node access modules enabled? (Or any other module that restricts access to nodes?)

Can UC see node/123 when not via masquerade?

higherform’s picture

higherform commented

Yes, I have several snapshot backups dating back as far as Nov 2008. What do you need me to look for?

Yes, revisions is turned on by default for many storm node types. I had found and turned off revisions for several that made for problems under 6.x-1.9 through 6.x-1.14 or so. Between 6.x-1.14 and 6.x-1.24 I do not believe I turned revisions on or off for any node types, but who knows they could have changed during a D6 core or storm module update?!?

Yes, we use nodeaccess and nodeaccess_userreference as well.

Just had one of my "providers" who used to have access to all projects and should still have access check... no projects listed at /storm/project even after a filter reset, access denied to all dozen or so project nodes we tested?!? But able to see organizations at /storm/organizations. I will ask a customer role person to check it also in the morning.

What else do you need to know / have me test? Long day and I'm not thinking the most clear at the moment, so I'm not seeing a clear pattern here... thanks for the quick reply though.

Magnity’s picture

Magnity commented

Right - I think the easiest way to find the issue since there is a bit of doubt over when the problems started is for you to setup a copy of your site from backup, then upgrade Storm one release at a time, testing for this issue. Stop when the issue occurs and report back.

There are so many changes that have happened between 6.9 or 6.14 and 6.27, so this will help narrow it down.

higherform’s picture

higherform commented

Since I am >50% sure this is a problem with my particular install and not a code defect, I am going to borrow a page from the CiviCRM wiki and ensure the db structure for my copy of 6.x-1.27 is "pristine" first, then copy current data into it and see if it solves the problem... if not then try the watchdog logging...

Rolling forwards from backup is a good idea, but even more time consuming than the above I bet... so, I will put that in as "Plan C" for debugging...

Thanks for the ideas.

Magnity’s picture

Magnity commented
Status: Active » Postponed (maintainer needs more info)

OK - will await your info.

Magnity’s picture

Magnity commented

Did you manage to solve this?

higherform’s picture

higherform commented
Status: Postponed (maintainer needs more info) » Fixed

Yes, by uninstalling all storm modules, reinstalling to get a "pristine" structure, copying the data back in, person->org->project->task/ticket chaining seems to be working again.

Interesting to note too is that the "duplicate ticket listing" issue was also solved by this, until the first time I edited a ticket. Now, all tickets show up twice for all users > uid 1.

Hope that helps

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.