Editing a case messes up project number

I am unable to duplicate this. Could you try to do some debugging on it?

I am getting the exact same problem.
pid changes to a random 3-char value after editing a case.

Drupal 5.0.1 & casetracker 5.x-1.1. What other information would be required by you?

I have the same problem. (4.7.x-1.0)
Before Сase Tracker I have installed (and setup) several modules:
+ pathauto
+ poormanscron
+ category
+ cac_lite
+ category_display
+ category_menu
+ category_outliner
+ category_pathauto
+ urlfilter
+ contento
+ nice_menus
+ janode
+ biblio
+ g2

When I have returned to edit form “case” and push “Submit” (with change or not – it is unimportant), then seen result:

Case number: -1 (up to that was “100-1”)
Project:
Opened by: …….

If I have set-off pathauto, after that have created new case, returned to edit form and “Submit”, then all worked correctly. After set-on pathauto the mistake has returned again...
To me it will be melancholy, if Сase Tracker and pathauto cannot work together...

xjm and Adalbert: You could list whatever contrib modules you have installed.

Pozniy: do you have either CCK or Views installed?

I have this problem on one 4.7 site (with a lot of stuff going on), but disabling pathauto did not fix it. I also created both a 4.7 and a 5.1 scratch site w/only casetracker and pathauto installed, and neither of them has the problem yet. I'm looking into a couple of other things that I think are suspect, and will report my findings when I have something.

Okay, I have found and narrowed down the problem for 4.7 (I was unable to duplicate it in 5).

All you need to do is this:

• Install a fresh copy of Drupal 4.7.
• Install and enable the casetracker, casetracker-basic and path modules (in addition to whatever else is installed, but that doesn't really matter).
• Create a project.
• Create a case (leave the URL path settings field empty).

Now, at this point you can edit and submit the node any number of times (well, I maxed out at four, so I assume any number) w/o any adverse affects.

• Edit the case and put something valid in the URL path settings field and save.
• Edit and save the case.

Now the case number is missing the project number.

Whatever the problem is requires something to be in that field before editing the case for it to break. I'm suspecting it has to do with the use of arg() throughout the code and the fact that path changes the number of parts to the URL, but I haven't pin-pointed that part yet.

If anyone else can get in there and find the exact cause, please let me know as I'm currently holding that functionality in limbo for an intranet I've created. I will keep plugging away at it until I solve it if no one else chimes in.

I'm trying to fix that broken bold tag thing.

More info:

Okay, I was probably wrong about the arg() idea as all my tests so far have yielded negative results.

I did, however, find something else out. There is a pid column in both of the castracker_case and url_alias tables. When this bad activity happens, the pid in the casetracker_case table is replaced with the pid from the url_alias table. The pid in the url_alias table is also replaced, but I have not yet determined where that number is coming from.

It looks like I wasn't entirely correct on the ID thing. It must have been a fluke that the IDs were the same, 'cause in trying to determine where the url_alias got it's data, I haven't seen the casetracker_case pid get the same ID, and the url_alias hasn't changed. :( Sorry for all the noise.

I believe this patch addresses and fixes this issue. In a nutshell, I changed the field names for the project form fields and adjusted the other code accordingly.

I'm using drupal 5.1, casetracker 5.x-1. (This is my first issue-post!)

Editing a case results in loss of info: case-number becomes a negative value (first one -1, -2, -3 etc.)
This is with pathauto enabled.

Disabling pathauto, create a new case, edit it: no problems.
I can't "repair" broken cases with pathauto disabled.

I'm also using Groups and Views modules, disabling those did not seem to affect the editing of cases.

> I can't "repair" broken cases with pathauto disabled.

I'll bet you can, if you go into mysql and manually repair your pid to be a valid
one, and null out the URL field.

I had to edit an existing case, null out the URL field, and submit. The change would occur,
but the pid was corrupt. I then manually edited the pid to be correct, and after that
I could edit that case to my heart's content.

yoroy: my patch doesn't apply to version 5, and your title isn't really meaningful for the bug.

All: I have still yet to see it even once w/Drupal 5.1 and the version 5 of casetracker. I'm not saying it doesn't exist, but I'm unable to reproduce it using the same steps I use to reproduce it in 4.7 (outlined in comment #6 above), so there may be something else that's causing it in version 5, and we need more information from those of you who are experiencing it. What other modules do you have installed and enabled? What possibly very different configuration settings do you have set? etc., etc., etc.

Morbus: regarding my IRC comment, the patch I submitted in comment #10 should still be good (pending your approval). My problem turned out to be something screwy going on with the install I had at the time.

my environment:
the stock local apache server on Mac OS X 10.4
Drupal 5.1, Configuration file Protected
Cron maintenance tasks Last run 16 sec ago, Database schema Up to datete
File system Writable (public download method)
GD library bundled (2.0.28 compatible)
MySQL database 4.1.21
PHP 5.1.6
Unicode library PHP Mbstring Extension
Web server Apache/1.3.33 (Darwin) PHP/5.1.6

I created a new virtual host on the local server and:
- installed fresh copy of drupal 5.1
- enabled path.module
- installed and enabled Casetracker 5.x-1.1 (Casetracker and CT Basic only), created 2 test projects with 2 cases each. Editing cases, no prolbems.
- enabled clean URLs. Manaully created an alias for both projects. Editing cases no problem.
- installed and enabled pathauto.module 5.x-1.0, leaving pathauto settings unchanged. Editing cases no problem
- installed and ebabled views.module. Created a basic view. No change in behaviour of the cases.

back to pathauto, changing some settings:
- checked "Bulk update node paths", a few new aliases were created
- AHA! editing an existing case (that got a new alias in the previous step) messes up the link to the project.
- Now, creating a new case. Edit it. Voila, link to project goes wrong too.

I forgot to add/edit a new case before bulk updating the node paths, so:
- disable pathauto
- create new case "X" and edit it, no problem
- manually add an alias to case "X", save and edit/save it again: no problem

- enable pathauto again
- edit case "X": link to project is broken.
- create a new case, manually give it an alias, save.
- editing this case again: link to project is broken
- create a new case, let pathauto generate an alias
- edit this case again: link to project is broken.

I'm not a developer, so can't help with drawing conclusions, but hope this helps!

yoroy, stop changing the title.

yoroy, I followed your directions as literally and as exactly as I could all the way through and never had the problem. Maybe you're leaving something out? If there is anyone else who would care to add your experiences to this issue, that would be most appreciated. As it is, I cannot reproduce it, so I cannot fix it (nor can anyone else).

my environment:
Kubuntu 6.10
Server version: Apache/2.0.55
Drupal 5.1, 2007-01-29
mysql Ver 14.12 Distrib 5.0.24a, for pc-linux-gnu (i486) using readline 5.1
PHP 5.1.6 (cli) (built: Mar 7 2007 12:48:25)
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 3.7.1
casetracker-5.x-1.1
pathauto-5.x-1.0
views-5.x-1.5

I am using both the project module and the casetracker on the same site. Since the beginning I noticed editing issues or cases messes up the project id (pid), so I disallowed editing of these node types to prevent the problem from happening.
It is perfectly correct that there's a problem with the 'pid' in the form: the pid from the url_alias table (eg node/679 registered at pid 2053 before update) gets copied into the pid field of project_issues' or casetracker_case's pid field after update, and of course node/679 gets a new pid in url_alias.

Therefore I conclude that the problem lies in the mixing up of these pids upon submittal, like oadaeh remarked. I don't know what to do at present: patch both project and casetracker, or patch pathauto? project is a core module, or as good as, so I think we should contact dww too about this. I'll file an issue there too (linking to this one here), and wait for a reaction here.

So it seems this issue is now being dealt with at http://drupal.org/node/128210 .
I'm posting a new patch there, which includes an alter table for two casetracker tables, and which renames all 'pid's into 'ctprid's. As far as I know, the patch posted here doesn't work properly (at least it didn't on my site).

This issue was being dealt with here for 4.7.x, which is what my patch was against, until yoroy kept insisting on changing the focus to the 5.x version of Case Tracker. The 5.x and 4.7.x code bases are different and the patch does not apply cleanly to both. That's when I decided to stop fighting with him and create a new issue for the 4.7.x code base.

In regards to your comments, adding Project to the mix will definitely add more of the same kind of problems for your site. Project is not, and never will be, core, because of it's focus. It is a heavily used and relied upon set of modules for drupal.org and kin, but is not something the average website will ever use (nor is Case Tracker, in that sense).

The problem is not with the Pathauto module, but with the Path module. The reason the Pathauto module gets the blame, is because it creates a path automatically, where the Path module requires the user to manually create the path -- something most users don't do unless it's for something like an About Us page.

It is entirely unlikely the Path module will be "fixed" for this bug, since the problem is caused by bringing in the contrib modules. Therefore, the Cast Tracker and Project modules need to be fixed, as it is their problem that they are creating for themselves, not the Path module creating the problem for them.

It is possible the reason the patch didn't work for you is because you also have Project module installed, and it is part of the problem, as well as Case Tracker. You would also need to fix Project module.

note: core is also broken. both book.module and path.module assume they "own" $node->pid. :( it's not clear if that's going to be fixed only via http://drupal.org/node/146425 (specific to book.module) or if i'm going to muster the forces for a more general, core-wide move to using module-name arrays in the $node object (http://drupal.org/node/148420), like so:

$node->book['pid']
$node->path['pid']
...

also, we'll be fixing project* for this bug over at: http://drupal.org/node/98278.

I am still having the same problem with casetracker on 5.x. I am unsure if I should install the 4.7 patch, as it seems most discussion has died (implying the 5 users found a solution somewhere.. possibly this patch?). I don't have the resources to do a reinstall of all of the modules on my site and find the exact point when the problem starts, but my problem is identical to the one described here http://drupal.org/node/125125 and here http://drupal.org/node/117685 . I would really appreciate some help if anyone has found a solution, or even has any ideas about how this may be solved.

Is this still a bug with the latest versions (1.3-beta & 1.x)?
never experienced this (I have fixed a $pid error in the past, maybe this is now fixed)

I found a comment from someone who experienced the same recently it seems: http://groups.drupal.org/node/10779#comment-35755

Create project - project number assigned is 100 > Create case - case number is 100-01 -> Edit case and reassign to another user -> case number now is -01 it lose association with the parent project

re-assigning to another user was the bit of info that might be a useful clue.

I'm also seeing this issue. I've got a WAMP install running drupal 5.7 and ct 5.x-1.3-beta1. I found that when editing an existing case, the project would be lost. Looking at the casetracker_case table, I noticed that the pid on the edited record was being set incrementally higher value after edit. So lets say the correct pid = 3, after edit it would be 14. Then I go and correct it back to 3 in phpmyadmin. Edit the case again, and the pid would change to 15.

I had path and pathauto modules enabled, so that case automatically got a path set. After turning off pathauto, and creating a new case, i could edit the new case no problem, since there was no path set on it. If I set a path and saved it was OK until I edited it again and saved, at which point the pid would be saved as 16.

So steps to repro (make sure Path is enabled, but not Pathauto)
1. Create a case, don't set a path
2. save
3. Edit the case and set a path (e.g. cases\this-is-my-case)
4. Save
5. Edit the case
6. Save
At this point the saved pid should be some unexpected number. It may actually work initially since I don't know where the bad pids start, but if it starts at 1, it may match an actual project's id. Setting the pid on the casetracker_case record to something good, and editing/saving the case with a path you should see the pid saved to something bad eventually.

Also, don't know if it makes a difference, but I'm using my own Case and Project content type with some additional cck fields.

Please read again my comment above. The cases get mixed up because castracker thinks it owns $node->pid, which is eg also used by the book module. My patch renames the casetracker tables and solves this problem. As I said above, this is an issue with quite some modules, which is being solved by some big drupal gurus, but is not solved yet, since it involves such fundamental modifications in the way modules store their variables.

Thanks for the info. Is your patch applicable to versions 5.x-1.3-beta1 or 5.x-1.x-dev

Hi all, I believe we've addressed the pid issue in the Drupal 6 port of casetracker that is happening now in casetracker HEAD. I don't have any plans to backport those changes to the 5.x or 4.7.x branches.