Forum OpenACS Development: Re: dotWRK: Project Manager
1. First of all, he'd like to be able to link Tasks and time logged in Logger. (jadeforrest: i definitely want a way to link time in time-logger to a bug in bugtracker)
2. He thinks maybe we can set up projects as keywords, which then can be used globally by other applications, such as logger and bug-tracker. They might be able to be used as the Project for logger, and the Component for bug-tracker.
Any thoughts on this? Here's our exchange:
[13:02] > daveb: That's the biggest problem with all these packages. They don't talk to each other.
[13:03] > daveb: so logger doesn't know anything about bugtracker, and bug-tracker doesn't know anything about project-manager..
[13:03] <daveb> jadeforrest: right. it can be done ina general way.
[13:03] <daveb> think general-links from the knowledge management stuff.
[13:03] <daveb> or just use cr_object_rels
[13:04] <daveb> you can link a cr_item to any acs_object.
[13:04] <daveb> similarly a site-wide category package would allow using the categories to define bugtracker bug areas and project areas and time logger projects.
[13:05] > I'm only vaguely following you.
[13:06] <daveb> you don't need to store the bug_id in the time-logger, for example.
[13:06] <daveb> store the bug_id and the time-logger item_id in an acs_rel
[13:06] > You could just link them using cr_object_rels (which I guess are like acs_rels)?
[13:06] <daveb> that way you can link two different objects.
[13:06] <daveb> yes exactly.
[13:06] > Okay, I get that.
[13:07] > However, linking the bug-tracker to the project-manager does seem like it will require a lot more coding changes, right?
[13:07] <daveb> why?
[13:07] <daveb> you don't need to directly link bugtracker to project manager.
[13:07] > I have to replace the components section with project-manager's Project table.
[13:07] <daveb> just allow links to objects from bugtracker.
[13:08] <daveb> some might be project manager objects.
[13:08] <daveb> jadeforrest: no. what you _really_ want to do is replace the components and projects with categories.
[13:08] > Tell me more :)
[13:08] <daveb> then bugs or tickets can be part of a category which happens to be a project.
[13:09] <daveb> bugtracker projects and components are already cr_keywords now in the latest version.
[13:09] <daveb> so you could use that.
[13:09] <daveb> i think :)
[13:09] > Hmmm, so you're saying that we create site-wide "categories", which are equivalent to projects.
[13:09] <daveb> the new category package isn't ready yet.
[13:09] <daveb> yes.
[13:10] > I don't know that much about the CR, unfortunately. Bugtracker projects and components are cr_keywords.. what does that mean.
[13:10] <daveb> it means that they are not bugtracker specific objects.
[13:10] > Does that mean they could link to "categories" instead of whatever projects you create in bug-tracker?
[13:11] > Oh, that's cool. I thought they were local tables specific to bugtracker.
[13:11] <daveb> well cr_keywords is the existing "categories" mechanism in the CR.
[13:11] <daveb> maybe they have local tables, but they should refer back to the CR stuff.
[13:11] > Damn, the problem is the more I learn about OpenACS, the more I have to learn.
[13:11] > :)
[13:11] <daveb> Actually everyone should start with CR
[13:11] <daveb> that is where most of the cool stuff is :)
[13:12] > Hmmmm, so if you were me, you'd spend some time studying the CR first, then figure out how to link all these applications?
[13:12] <daveb> yes.
[13:12] <daveb> of course I have spent 2 years on and off studying CR :)
[13:13] > Do you think I could use bug-tracker without forking it? I do have to add things to it, like dependencies between bugs
[13:13] > (for project-manager type Tasks)
[13:13] <daveb> well, consult with the author.
[13:13] > I will.
[13:13] <daveb> maybe they would like that too :)
[13:14] > I'm going to have to chew on this a bit.
[13:18] <daveb> i would definitely attempt to not fork anything.
[13:18] > Well, it would not really be forking bug-tracker, but taking bug-tracker and using it as an example for another application built on workflow.
[13:19] <daveb> anyway bugtracker is aimed to be more general purpose.
[13:19] > True
[13:19] <daveb> but still in the end you would have two packages with similar code.
[13:19] > Yes.
[13:19] <daveb> maybe you can build a package on top of bugtracker alsom using bugtracker as a service.
[13:19] > Which would be not good if it were possible to keep them together.
[13:19] <daveb> it might not be possible.
[13:19] <daveb> but definitely look into it.
[13:20] <daveb> anyway good luck :) bbl