Comments of comments.

Nodecomments is following drupal core comment module on this so it's valid behavior. You are using Node Comments for reviews which is one of the possible scenarios but it's not main usecase for the module.
The fact that it allows you to set different content type as review comment type is a minor UI bug.

It could be feature request, but it would involve much of UI complexity. For example, all links would stil be "Add comment", so how would user understand he's leaving a comment rather than review ? That would require special handling.
In summary, I recommend to use different solution for reviews such as Node Reference. Node Comments is most useful for comments.

It seems I was wrong. We have comment node type in links by default. That means we can make this work properly.
But it would be very complex, because of threading: you would get 2 links on "review" node: "add comment" and "add review". "add review" would be link that continues old thread, and "add review" would start a new one.
Note that in your scenario you don't want your review to be reviewed, so that wouldn't work for you anyway.

Let's switch this to a task. I still think that current behavior is a valid one, but I'm ready to discuss possible implementations of this feature.

but the way NodeComment is designed should resolve this problem,

Node Comments was made to replace comments, not to implement review systems. It just can be used for this, in a limited way, but that doesn't make it designed for it.
Review systems have own requirements, and they should be implemented using tools designed specifically for them.

(or you should remove the permission to add NodeComment on a node that is already a Comment)

Why should I ? You are allowed to comment comments. That's threading - a feature of most comenting systems. You are just not allowed to use separate content type for that.
As I said - the fact that you are allowed to select different comment type for nodecomment type is a minor bug, because the setting doesn't work. Otherwise, it's working as intended.

I guess I will make nodecomment_get_comment_type() function to always return same type for nodecomment, and also will make comment type selection invisible for nodecomment types.

For the bugfix, see #799052: Node Comments module allows to set different comment type for a nodecomment, misinforming a user.

My thoughts summary.
I have many questions about implementation of this feature:
1) What would be usecase for it, besides reviews (which do not fit into comment workflow well) ?
2) If you wanted to have different (secondary) comment type for a nodecomment, would you want to be able to comment using primary comment type aswell ?
4) If you wanted to comment using different type, would you want to start a new thread or continue the old one ?
5) If you wanted to continue the old thread with different comment type, would that work at all ? Nodecomments has lots of conventions, and such advanced feature could require reworking a lot of code
6) How are we supposed to fit it inside the UI so typical user doesn't get mad ?

I think after these questions you should understand the complexity of this feature. If this is going to be implemented at all, it will be done in 3.x branch and most likely not by me. Postponing this, but if anyone have thoughts, feel free to share.

Hi - what is the status of this? Is it achievable using the module as it stands at the moment with a few modifications?

I have a use case, although it is pretty specific and I can't think of how it would be used on other sites (except maybe educational ones) - it's a bit like using the commenting system to organise debates.

Basically, I have a requirement for a three tier commenting process.

Initially, a user will provide an issue to be discussed (Forum Topic) - this should be the main node. The Forum Topic and has the comment-type set to 'Forum Post', which is kind of a position statement or opinion on the issue. The Forum Post has the comment-type set to 'Comment' - this would allow users to comment on each others position statements and keep these separate from the 'position statement' comments.

So the page displays the Issue (Forum Topic) with the Opinions (Forum Posts - these can be added to by users), and each 'opinion' displaying the Comments on that opinion below it. Users can add a new opinion by clicking a link under the main topic, or add a comment by clicking a link under the appropriate opinion - so there would be no confusion as to which 'add' link to click.

I would like these to be separately themeable. Node Comments is necessary because I require the use of different cck fields within the different comment-types.

So, my questions are:
1. how feasible is this three tier system given the system as it stands?
2. how much coding do you think would be necessary to achieve this? (if it isn't that much I would volunteer and contribute - I will have to achieve this functionality for a project I am working on one way or another - this way or maybe through views or something) - but I am up against a deadline and would have to start and finish Monday.
3. Am I missing something obvious and is there a much easier way to achieve what I am after.

Cheers...

This sounds almost exactly what I'm trying to do right now. In my case there's an admin created issue (a cck node with details about the issue referencing other nodes etc). Replies to this (nodecomments) would be position statements as you call them (a yes or no, a summary of the users reasoning and a flag tallying changes of opinion). Each of these would be commentable in isolation in their own node in the normal manner. But obviously, the nodecomment type used in the second tier isn't suitable for these third tier comments.

I've toyed around with nodecomment but as yet haven't found a way to use more than one type nodecomment. If you can figure out a way around this I'd love to know.

I have reviews on my site and it would be great if this could be made to work. It would make the "comment" node a hybrid that is both a child of another node and capable of having its own children. Similar to threading, but not exactly the same.

For me, simply allowing core comments on a "comment" node would suffice. Allowing a different "comment" node type on a "comment" node makes my head spin. :) But allowing comments would allow for mini conversations like on Facebook as etherx mentioned. In the case of reviews, it would be something like this:

Main node: XYZ Flower shop [Link: Add review]
 \_ Review 1: Smells lovely [Link: Add comment]
 \_ Review 2: My flowers were dead [Link: Add comment]
        \_ Comment 1: Sorry to hear that. Come back and we'll get you nice ones. [No add anything links]
         \_ Comment 2: Great! [No add anything links]
  \_ Review 3: I hate flowers [Link: Add comment]

Limiting it to core comments and not allowing threading might be too limited for some use cases but would simplify it quite a bit. Thoughts?

Michelle

Michelle - to have a system like that would be so ideal for me!

I was wondering if there may have been any development in 'comments of comments'?

Thank you

All what we talk about we can do with Node Reference URL Widget and Views attach modules.
But do that with Node comments is more ellegant way.

Subscribing. Another common use case might be a Q&A style thread.

subscribing. This is awesome.

Ok, I inspected the code and enabling this doesn't require much from the point of logics. But we now need advanced UI for that.
I think there will be some limitations:

• If a node is both a "comment" and "content", breadcrumbs will be set up according to "comment" context
• If a node is both a "comment" and "content", generally we allow all "content" features: the node will have own page, usual node settings, etc. Also, title will be required and not just set to "Re ..." behind the scenes.
• I think we may need to stop redirecting to target node (the node we are commenting on) if the comment is also "content".
• More coming..

Most of these settings will be hardcoded. Having them all configurable in UI is a nightmare.

This is fixed, generally. Please open separate issues for bugs or suggestions regarding this feature.