So I've got a couple node types that were not currently within casetracker. They each have some nodes and I wanted to throw them into projects as cases. I first setup case tracker to handle this at /admin/settings/casetracker, setting these new content types as viable case node types. I then created a couple of projects. Upon editing one of my custom content types I now have the case tracker options at the top. A dropdown for my projects, and the assign to with populated users, as well as the case status, priority and type fields. When I set these values and save the node however, the values do not seem to save at all. The node displays with 'Array' in each section on the node view and upon editing again, the values are set back to defaults.
Node view: (note the last updated field is not correct either)
Node edit: (looks pretty good, except it's always default values)
Any clues would be appreciated. Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | casetracker-preexisting_nodes-734542-12.patch | 780 bytes | agileware |
| #10 | casetracker_734542.patch | 914 bytes | sirkitree |
Comments
Comment #1
sirkitree commentedNode view: (note the last updated field is not correct either)
Node edit: (looks pretty good, except it's always default values)
Comment #2
jmiccolis commentedI've certainly seen this "Array" business before, but I'd though I'd crushed the corresponding bugs. From the screen shot I an see this isn't a vanilla Drupal install. Can you reproduce this bug on a basic install?
Comment #3
sirkitree commentedYes.
Basic install, generate some stories and pages, then install casetracker. Set page to project node types and story to case node type.
Edit the node, give it some case tracker settings.
Save and still have Arrays.
Comment #4
jmiccolis commentedWhat's happening here is that case tracker assumes that you won't try to use it's functionality on pre-existing nodes. Generally I think this is a fine assumption, but that we could be a bit more graceful about it. I'm tempted to simply omit the case tracker interface for existing nodes that were created before case tracker was enabled. I'm open to going a bit further, and making it possible to add case meta-data to existing nodes... but left on my own I'd just hide the interface.
thoughts?
Comment #5
sirkitree commentedSo my use case here is that we have an existing site that is used for our intranet and I migrated it to Open Atrium. We have a few nodes that are used to track different project types so when I enabled all of the OA features I thought casetracker would be a great place to put these and expand upon our current functionality a bit.
I'm not sure if this is a use case that happens often, but I am planning to blog about the experience as well and it would be great if this worked. Currently we basically have to recommend migration of the old project types into new projects/cases. So it's probably not a high priority other than this use case.
I'd also be willing to help out if you'd like to add this, but haven't taken apart the code just yet to build it out. Can you give me a good idea where to start to hasten my progress?
Comment #6
jmiccolis commentedThe core of the problem is that casetracker just assumes in casetracker_nodeapi('load', ...) that a row will exist in the casetracker_case table for that node. When it doesn't exist everything falls apart, you get the 'array()' garbage you're seeing and any invocations of casetracker_nodeapi('update', ...) silently fail because the sql update statement is an UPDATE and does nothing because the row it's trying to update doesn't exist.
So, we've got a couple options:
Number one is a the bare minimum we should do, and like I said, it's what I'd be willing to do here. Let me know if you feel like tacking either of the other potential solutions.
Comment #7
Grayside commentedThis looks to me like a data migration issue, and is possibly solved by better casetracker support in other migration modules. (Such as Feeds.)
Option #1 makes sense to me. Or re-importing the data after working on Feeds mappers (etc).
Option #2 seems like something to address in CT2.
Comment #8
sirkitree commentedOption #2 looks like the best option. I'll start by writing a script to do this and then we can plug that into casetracker_settings_submit
Comment #9
jmiccolis commented@sirkitree, so a few of the issues that I'm worried about:
* Making sure whatever we do scales to a few thousand nodes, ie it needs to be able to complete within normal page load times, or we need to use batch api, which I'd like to avoid.
* We may want to add a confirm screen before invoking batch api, or allow the admin to choose if the system pulls in existing nodes or not.
* Make sure that we can gracefully handle strongarm style changes to 'casetracker_project_node_types'. In atrium type scenarios I use strongarm to control this variable. So there isn't a single point where you can be sure that all changes to the "which node types are cases" settings is routed. Given that this is a case it may be that a using the submit hook on the settings page isn't the way to go.
Comment #10
sirkitree commentedHere is a quick fix that will simply allow you to edit a node that you've set the type as a casetracker type, set your casetracker options and will create a record for it on update.
This does not include the multiple node updates yet.
Comment #11
agileware commentedThe patch in #10 successfully implements fix 3 from #6. At least for me anyway.
Comment #12
agileware commentedChanging to feature request as it is a known to be unsupported feature as opposed to a bug.
Here is a reroll of the patch in #10 that applies with patch -p0 from the casetracker module directory.
It also applies cleanly to the current dev verison.