Hi,

In my content type list the first three content types have the proper new Comment Driven option in the new column, however after 2 content types in the list (the default blog and book) the third one is not the right one (it jumps to the Event type - 4th in the list, when the next one should be Case - the actual 3rd one). This might be linked to the fact that the content type that's skipped is the default Case tracker case node type casetracker_basic_case. There is an easy workaround this since if you click Edit or Manage Fields for the content type, then the Comment Driven tab is there and properly linked.

However I encountered another problem and I wonder if they are linked (and linked probably to an incompatibility with Casetracker):

In the permissions page the problem is different only 4 conent types are listed with the ALL option:

drive ALL properties through comments (for EVERY content type!)
drive expert properties through comments
drive feed properties through comments
drive feed_item properties through comments
drive graphmind properties through comments

This is on an open atrium install, and although I had casetracker_comment_driven installed, when I deactivate it, the problem remains. Drupal is 6.19. And this happens with both Comment Driven Alpha3 and dev from July 11th.

Best,

Jun.

Comments

arhak’s picture

arhak commented

did you tried with Driven API -dev?
the shifted links are supposed to be fixed since #814726: links are shifted at content types' overview page (when having custom content types, e.g. panels_node)

the permissions page problem is another thing
but I didn't get enough details

only 4 conent types are listed with the ALL option

how many did you expected?
which ones?
which are contrib module's built-in, or CCK built through UI?

jun’s picture

jun commented

Indeed going with -dev fixed the issue.

Good question about permissions which I think makes me understand were that permission "problem" came from. Indeed the one I wanted to see in the list is from a contrib module, I guess it's just that this permission hook is not implemented yet by casetracker_comment_driven.

Is it proper to move this as a feature request to that module's issue queue?

Thanks!

arhak’s picture

arhak commented

Is it proper to move this as a feature request to that module's issue queue?

not sure
which is that mysterious content type of yours?
isn't it returned by the function node_get_types()?

I'm reviewing comment_driven_perm (hook_perm) and I see

  foreach (node_get_types() as $type) {
      if ($type->module == 'node') {

ah... of course, the module of your type isn't 'node'...

use Execute PHP (devel module) an run the following:

foreach (node_get_types() as $type) {
   print $type->name . ': ' . $type->module;
}
jun’s picture

jun commented
Title: Comment Driven option in Content Type list mismatched and permissions missing for some content types. » Permissions missing for Casetracker content type.

Just a reminder that I'm on an Open Atrium install. And what's not

Here's the list you asked (seems like features actually hides the original module responsible for the node type):

Blog entry: features
Book page: features
Event: features
iCal Feed: features
iCal Event: features
Group: features
Profile: features
Status: messaging_shoutbox
Project: features
Case: features
Feed: node
Feed item: node
Question: features
Reader feed: features
Expert: node
Links: features
Todolist: todolist
GraphMind map: node

In the Content Type list page Case is defined as Case casetracker_basic_case

arhak’s picture

arhak commented
Category: bug » feature

so, do you expect a "drive XYZ_TYPE properties through comments" for each of those content types?
isn't too much / overwhelming?

I constrained it to the ones assigned to node module because at the time I thought it would be the best choice
but if you want them, you should be able to have them
so I think it would be better to have a configuration flag to enable the bunch of permission, but keeping the default behavior more lightweight

don't you think?

arhak’s picture

arhak commented

BTW: auzigog (the maintainer of casetracker_comment_driven) has CVS access to this module, so you might want to share your ideas with him and both of you come up with something for cdriven's HEAD

arhak’s picture

arhak commented
Title: Permissions missing for Casetracker content type. » Missing for some content types (those not handled by node module)
arhak’s picture

arhak commented
Title: Missing for some content types (those not handled by node module) » Missing permissions for some content types (those not handled by node module)
j0nathan’s picture

j0nathan commented

Subscribing.
Coming from #928096: I have no permission "drive forum properties through comments" under comment_driven module

bibo’s picture

bibo commented

subscribe.

I think I'm having the same problem, or at least related to this. I wan't my casetracker_basic_case-nodes editable by everyone with a certain role, undepending of node author. (The author is a dummy user that creates tickets from mail via mailhandler).

I'm using content_access + casetracker + comment_driven, and I'm wondering why I can't set permissions for "casetracker_basic_case". Currently it only works if I give the role "administer nodes".. which I don't want.

arhak’s picture

arhak commented

@#10

Currently it only works if I give the role "administer nodes"

not sure if your problem is related to permissions exposed by this module

this module exposes "drive XYZ properties through comments" permissions,
which relates to properties being modified when commenting,
not related to node edition (there is a sub-module which does relate to node edition permissions, but only to control per-field permissions, not the whole node edition) therefore, if "admister nodes" serves you as a workaround, most likely you're having another kind of issue

socialnicheguru’s picture

socialnicheguru commented

I had the same issue on a production site.

If I have a node be part of a feature then it does not show up under comment_driven permissionsl

I had to set "drive ALL properties through comments" for authenticated users which is ok for now.

could you just do this from #3 above to have it access all node types.

<?php
  foreach (node_get_types() as $type) {
      if ($type->module) {
?>
arhak’s picture

arhak commented

@#12 for those in a hurry, commenting out that "if" would do the trick,
but re-applying patches might be tedious

for a final solution the first thing we need is a proposal,
patches are welcome

just consider my remark @#5

I think it would be better to have a configuration flag to enable the
bunch of permission, but keeping the default behavior more lightweight

PS: by "consider" I mean "evaluate" (don't read it as a mandatory "include it", it is open to debate)

arhak’s picture

arhak commented

marked #1292128: Permission for more content types as a duplicate