First of all let me say that my involvement with this is peripheral. I haven't looked at the code or the customizations. I'm only aware of this because of the recent difficulty that's been encountered with implementing issue summaries on Drupal.org. Project Issue Tracker has served its purpose well but is now becoming outdated because people want to do things with it that it was not designed to do, and the current design seems to be getting in the way of these new developments.

In the past, everything in Drupal was a node, because that was all we had to work with. But Drupal entities now offer a lot more power, efficiency, and flexibility. It occurs to me that a project issue is a good candidate to implemented as an entity in Drupal 7, for several reasons.

1. Revisions. With the introduction of issue summaries, an issue needs to be able to handle revisions, but not necessarily in the same way that a node does.
2. Access control. A project issue does not need all of the access control capabilities of a node.
3. Flexibility. Not all applications that use Project Issue Tracker have the same needs. A case in point is the Full Project Applications queue. With entites, it becomes much easier to customize. Creating a new issue type is on a par with creating a new content type.
4. Custom processing. Implementing an issue as an entity would provide an opportunity to re-think how things are done.
5. Future development. Creative people are likely to come up with more things that can be done with an issue entity. Development will be easier and probably more fruitful with a custom entity.
6. Conceptually correct. In entity-relationship modeling, an entity is just something that you want to keep track of information about. A project issue fits that description. It is not necessarily tied to a specific project, but can have a life of its own, and has many attributes of its own that need to be managed.

It's a lot of work to implement a new entity, but considering the things that people want to do with issue queues, it might be worth the effort. On the other hand, it might be a completely lame idea. A big issue would be how to upgrade.

Comments

EvanDonovan’s picture

Interesting points...subscribing. I've never developed for PI though, so don't have much to say, at least not currently.

Damien Tournoud’s picture

This + http://drupal.org/sandbox/tstoeckler/1093448 has the possibility to remove most of the code of Project issue.

ccardea’s picture

If I understand correctly, tstoeklers project is sort of an abstraction of what Project Issue does, i.e. it uses comments to change the node. That is one of the things that I originally thought should be looked at. As an outsider looking in, it seems a little strange to have the comment change the node. But it is kind of the signature of what Project Issue does, and it does provide a useful permanent record of who changed what.

But now we have issue summaries that allow for revisions of the node. My immediate impression was, if you're going to allow revisions, then it might be more efficient to put everything that changes the node into the revision process, instead of using comments to change the node.

If you want to do that, then it probably does make sense to think about making an issue an entity. If you want to keep that comment process though, I'm not sure that it does. In either case, Project Issue is such an important module for Drupal.org, people really should be thinking about porting it to Drupal 7.

ccardea’s picture

Another problem with creating a special entity would be comments. I think comments are fairly closely tied to nodes. Does anyone know how much of a problem it would be to attach comments to another type of entity?

One of the things the Prairie Initiative people want to do is have different categories of comments. That would make comments sortable and filterable. That could be done with a field added to comments, but might be more efficient with a column added to the comments table, or a new comment type(s) specific to project issues. I'm not sure how this would be presented on the page.

ccardea’s picture

The comment problem probably kills this idea. Comments and nodes are joined at the hip, and allowing a comment to attach to another entity type would require separating these conjoined twins, major surgery indeed. Not likely to happen any time soon. So making an issue an entity would probably require coming up with a system to replace comments on issues. That's do able, but, is it desirable and is it worth the effort? I don't know.

dww’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev
Status: Active » Closed (won't fix)

No, we don't want issues to be entity types. We want them to remain nodes because:
- We want comments on them
- We *want* revisions
- We want 95% of what nodes are
- It's still flexible so long as we define the node as a generic node type with core (and contrib) fields instead of hard-coded fields like we have now
- You can still define multiple node bundles (node types) for different kinds of issues if you really wanted to
- Link rot for existing issues
...