Allow posting comments but not starting new topics

Actually, this was the behavior we had in D5, and many of us saw the inability to control comments as a missing feature. We added it in #310254: Control posting rights for comments/replies in D5 for D6 (and it proves difficult to backport it to D5), but I see now that the old behavior was useful, too.

I'm not so eager to add more columns — maybe just a global switch?

I need this also for a site updates/polls/news forum section that only moderators/admins can post in, but users need to be able to comment on the posts.

A global switch would be ok in my case, I think. I don't really have any need to restrict both commenting and posting nodes. Couldn't say for anyone else. <_<

I want that future too, but in specific forums, not whole the forum :(
(etc at the forum "announcements, but not at the forum "ask for help" )

I have implemented 'Drupal 5 legacy mode' to allow a smooth upgrade from Drupal 5; see #552636: Forum post vs. reply not functioning correctly.

I'm still undecided whether to offer this for individual forums (i.e. a checkbox per forum) or even for specific roles (i.e. splitting the Post column in two).

If we split Post, will we have to split Edit and Delete, too?

Anyone posting actual nodes there would be a moderator already, and already have edit or delete privileges, correct? Only the ability to add comments are being changed I thought. Maybe I don't understand. <_<

highvoltage: I'm confused by what you write. People can be moderators (with all rights), they can have Post rights, Edit rights, and Delete rights. That's all completely independent. In D6 mode, comments are treated like posts, in D5 legacy mode they're unaffected by Forum Access.

There's no distinction between creating a node and posting a comment in the permissions?

Exactly. This is what it says when you open the 'Permissions information' fieldset. Both need Post and their respective Drupal permissions.

So is there any solution to overcome this problem, without hacking around?

See #4 above.

Thanks salvis.

I think we should split the create a new topic and create a new comment, because they are two different things on drupal. Each one with its own settings. So we have to think them as separate. And of course i think it must be per role for all the forums.

I dont think to split edit or delete, because if someone has the permission to moderate content, he/she should moderate both topics and posts. Because a topic with its comments it is one logical entity. If i have the permission to edit/delete a node, i want to have the permission to edit/delete its comments too.

apanag

Hello,

do we have any updates about spliting the permissions?

Thank you,
apanag

No, do you want to work on it?

I am going to try a few things, but i ll have a deadline for a project at 2/10. So until then. i am going to code as much as possible.
Firstly i am going to read your code and try to figure out what happens in it.

I personally would like to see this implemented to be configurable both on a per-role basis and on a per forum basis. The 'Announcement' scenario is exactly what I'm looking for (#3 above). I don't see it being necessary to split Edit and Delete, for my purposes at least, but I suppose to could be implemented for completeness.

I'm thinking things over and I think I may go with the Node Comment module so that I can have comments with CCK fields and permissions. This will make my need for this feature moot, since I would need to use the Taxonomy Access Control module to do what I need to do.

Adding Node Comment support to FA is another item on my list...

Any updates as to when this module might be fixed?

I'm not aware of anything that needs to be fixed at this point.

Whatever needs to be fixed so that users can't post new topics but can still comment. Any news on that being fixed, whether you were gonna do that drupal 5 legacy thing and have the module ignore comments altogether, or split the post column into two columns, one post, and the other comment?

You're wasting my time. Please read the thread.

I did, and it was already obvious you weren't planning on doing anything about this issue. I was actually asking Apanag since he said he might work on it. He doesn't seem to be answering though. I do think the module would be much better if the post permissions were split into two columns though, although judging from your response it doesn't look like that will be happening anytime soon. I guess I'll just try the node comment module and the access taxonomy module combo that fersman4 suggested.

The D5 legacy mode is implemented as per #4.

Beyond that we're talking about feature requests, not things that need to be "fixed".

Add me to list of those who would much appreciate per-forum ability to allow comment posting w/o allowing new topic/node posting.
I'd gladly submit a patch if I knew how to write one. Still dependent on smarter people for that.

Had this issue myself but I could personally fix this with D5 legacy mode as I did not need very granular control. Took me a couple of minutes to find where the setting was though, so to be sure, it is located at admin/content/forum/settings

+1 to have this as an option in the form of a permission.

and yes, if "post" permission would be split up, it should also have to be split up for edit and delete obviously.
Maybe it should look a little bit more like the general permissions page in core?

What are the implications of D5 legacy mode? I don't really understand, and searched but could not find.
I turned it on and it works indeed.

And how will all that translate to D7?

thanks

I'm not sure about splitting up edit and delete. The sweet spot is somewhere between global and finest-grained. I doubt its at one of the extreme ends.

What is it in the explanation of D5 legacy mode on admin/content/forum/settings that you don't understand?

If we get split Post in D7, then D5 legacy mode will go away.

I'm not sure about splitting up edit and delete. The sweet spot is somewhere between global and finest-grained. I doubt its at one of the extreme ends.

I dunno.. it's a "feature" you will see in any professional forum package so I don't see why it would be redundant in a forum access module.
But I understand there might be D6 architectural motives for your current opinion on this matter.

- What is it in the explanation of D5 legacy mode on admin/content/forum/settings that you don't understand?

Oh I do understand, I was just wondering about further implications for the rest of the site and other contrib modules.
And so there are implications now I think about it..
I have a forum where all "closed" topics get moved to. Normal users don't have permission to post there so they can't add comments to the "closed" topics by D6 design.
If I enable D5 legacy mode, I won't be able to stop people from adding further comments to those closed threads.
I see "locking topics" will be a feature for D7 so that would solve it.

Thanks for your time.

+1 for splitting edit and delete. This is indeed a pretty industry standard forum feature.
But posting w/o starting new threads... even more basic.

You're asking to double the number of checkboxes. It seems that we have to double them again to handle unpublished content...

I don't see why the number of checkboxes would have to be expanded much.
Why not just add a "allow comment only" (or something like that) per role?

Comment only what? View? Post? Edit? Delete? See #27...

Where should we draw the line?

I was still thinking in terms of the original post... just permission to add comments to a node without permission to add nodes. So "view" would have to be included, of course, but edit/delete not necessarily. I do see the difficulty in where to draw the line. Maybe it needs to be a separate module.

Focus is shifting to D7: this could go into 7.x-2.x after 7.x-1.0 is released.

A backport to 6.x-2.x would only be realistic if someone completes #762270: WANTED: SimpleTests for Forum Access...

+

This patch adds a new permission, 'comment', which grants commenting on any topic in a forum.

It is supposed to:

• Preserve the current default setting for new installs and upgrades to this patch. The database update is supposed to copy the `post' permission's value to the `comment' permission for each ACL entry (but unfortunately I am not certain that his part works, testers?).
• Only splits out the `post' permission into `post' and `comment'. I opted for this since this is all I need for the prevailing scenario (an announcements forum with comments only and posts by admins only)

It lacks:

• New simpletest test cases
• Micro-management concerning the edit and delete permissions for comments. The argument against supporting this, I guess, is that if one has the permission to delete a node that person is responsible enough to delete comments. The only problem is that some sites might want to grant the ability to delete comments to a particular forum to a moderator, but this sort of thing is probably better handled by spam-management modules instead of forum_access?

edit: P.S., I'm interested in backporting to drupal6 if/when this patch is beaten into something acceptable ;-).

Ah, that's a great start, thank you!

I recognize the value of your Comment permission. OTOH, I'd like to keep FA as slim as possible.

Having separate Post and Comment permissions implies a certain mode of operation of a forum, for example, members of the Board of Directors can comment and start new discussions but normal association members can only comment in existing discussions.

If that's how you want to operate a forum, this is exactly what you need. However, many forums (probably most forums) don't have that two-tiered membership and for those the introduction of a new permission (that they'll have to maintain in sync with Post manually) is a pain.

Could we make the Comment permission optional, i.e. hide the column (and keep using Post for both nodes and comments) until the admin requests a split of the Post permission (per forum)?

You're trying to keep complexity down by introducing only one new permission, but I'm sure that requests for View, Delete, and Update Comments will follow, and we should be prepared for that.

Could we make the Comment permission optional, i.e. hide the column (and keep using Post for both nodes and comments) until the admin requests a split of the Post permission (per forum)?

That sounds reasonable.

This feature is definitely needed, and I would argue all the granular permissions for post, edit, and delete.

There are problems with both options at the moment:
- The problem with using Drupal 5 legacy mode is that mods cannot edit or delete other users' comments without having the global administer comments permission. And that permission lets a mod edit/delete comments site-wide, not just the forum they moderate.
- If you don't use D5 mode, then you cannot have a forum where only certain roles are allowed to post topics, but everyone else can comment. I would guess that this is a fairly common requirement (it is on most sites I work on).

I think the UI complexity - which seems to be the main reason being given to resist this - can be overcome by redesigning the permissions UI so that it uses a table just like the main drupal permissions page. This would remove the repeated role names which make the UI look more bulky that it actually is.

Permissions that I would include:

- View Forum (applies to both nodes and comments, I can't think of why you would need to separate these)
- Post Topics
- Edit Topics
- Delete Topics
- Post Comments
- Edit Comments
- Delete Comments

Put them in a table as rows with the roles as columns, just like the Drupal permissions page.

I think it would also be good to provide some clarification that the Edit and Delete options actually apply to all user posts/topics, not the user's own ones (which can be controlled in the main Drupal permissions page with the edit own topics permission).

Put them in a table as rows with the roles as columns, just like the Drupal permissions page.

No. The number of permissions may grow, but not indefinitely. OTOH, there's no limit to the number of roles, and these should go downwards.

Maybe its time core provides a general pivoting function, but that is another issue. Yet another is the ability to "freeze" the left column as is currently done with the role titles: when scrolling horizontally, the left column should stay on screen when there is more to see beyond the right side of the visible area.

Edit: scratch my last comment, I did not read this thread very carefully before posting.

If the permissions would be named as suggested in #43, and not be many more than that, then obviously they should be column headers, having roles flow downwards, as they may be many more.

Sure, whatever. It would be better either way. I suggested that way as it is consistent with Drupal admin.

Is there any progress on this issue?

No, this will not start before 7.x-1.0 is released.

You can help to get us there by testing beta and rc versions and posting positive comments under #809404: Forum Access for D7 if everything works or bug reports in new issues otherwise.

Hello.
I've installed the .patch above, and trying to apply some rights I receive series of errors:

"DOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'grant_comment' cannot be null: INSERT INTO {forum_access} (tid, rid, grant_view, grant_update, grant_comment, grant_delete, grant_create, priority) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3,

...

[:db_insert_placeholder_86] => 0 [:db_insert_placeholder_87] => 0 ) в функции _forum_access_form_submit() (строка 633 в файле ***/sites/all/modules/forum_access/forum_access.admin.inc)."

... and nothing applies.
Is the patch working? Could anyone help me to solve this problem?..

If you assign yourself, that means that you're going to work on it and no one else should touch it until you come up with results.

Oh, salvis, excuse me... I did it accidentally. Corrected. (Ooops...)

I have this problem that posting comment is allowed but creating a new forum topic is not allowed for any user except administrators.
the DNA shows the Relatedlinks module denies this access as shown in the picture.

@mfby2k: #54 is completely unrelated to this feature request.

Please post this in the Relatedlinks queue. The Relatedlinks maintainer should figure out what is going on in the first place (whether Relatedlinks is behaving as intended), and when that is cleared up, it may need to be moved to the Devel queue for investigation as mentioned in the hint.

To be useful, we'll need a full screenshot of your DNA blocks.

thanks for your reply

I have posted it to relatedlinks issue queue here is the link http://drupal.org/node/1444022 but got no response.

I was searching for it and found this post closely related to my problem so i posted here in hope of getting some help.
I have also discussed it with Advance forum issue queue (Michelle ). She also cant figured it out.

I have attached the full view of DNA block.

found this post closely related to my problem

I said it was completely unrelated. Since you don't accept my judgement, I won't waste my time with you.

Hijacking threads is unacceptable. Get out of this thread NOW!

OK dont be so angry

it is not closely related to my problem i accept your judgement. This thread request this feature which i want to get rid off. all the registered user can comment on forum post but can not start a new thread.

will you help me...

Is this functionality still in progress? It would be extremely useful to me

This has not started yet.

#40: forum_access-545916-d7.patch queued for re-testing.

This is a patch against 7.x-1.x-dev based on #40 with one slight change - it adds create comment permission (comment_create fields vs comment field). If in the long run this module needs to support comment edit/delete then at least the field names will make sense.

Make sure to run updates or your users will not be able to post comments in forums!

Please set the status to activate the testbot.

I'm not sure whether the testbot is able to apply the database update, but I get 40 fails locally even after running update.php.

Here's an updated patch with the tests updated as well to accommodate this new access permission. The tests were failing because I never updated them.

What is needed to get this committed?

Sorry for the delay. Thank you for getting this to pass.

Please preserve the coding style: things that are aligned should remain aligned when a new (longer) item is inserted.

We will need tests for the new functionality, just like we have for the existing one.

What is needed to get this committed?

We have to get a few people to care enough about this functionality that they'll review your patch. If you're the only one who is interested in this, then it does not make sense to commit it.

Posting a screenshot of the changed interface might help to raise interest.

We have to get a few people to care enough about this functionality

I will try this patch on my test D7 installation.

I've have the patch running on my test D7 environment and it all seems to be working as it should at present but I'm still reviewing it.

Reviewed the patch. Works like a charm.

Patch works as expected for me. Remember to run update.php after applying this patch. I'm running Drupal version 7.22.

Noticed a problem with comment permissions. We're not using the "edit own comments" permission anywhere. As a result, the _forum_access_comment_edit_callback and _forum_access_comment_access_callback are returning incorrect values for these permissions. I went to my permissions and unchecked "edit own comments", but regular authenticated users can still edit their comments.

Also, I'm not sure if this is intended, but the "edit" link doesn't disappear even if the user does not have permission to use the link. Is this a result of chaining permissions together?

From Permissions information:

The global Edit own comments permission is ignored, but the edit/delete forum content permissions are extended to comments; the per-forum Edit and Delete apply to both nodes and comments, too.

I'm not sure whether #76 really concerns this feature request. Please open a new issue if it doesn't.

Reviewed the patch.. seems to do the trick on D7.22

Eric

Tried the patch in several sites, works like a charm, thanks :)

Great, thank you for the positive feedback.

As per #71 we have a few coding style issues, and we're missing tests. I've spent many days developing tests for close to 100% coverage (of the security-relevant code), and I won't commit such a change without proper test coverage.

Also, I haven't actually gone through the patch with the fine comb, so there may be more bumps ahead, but at this point we're blocked by #71.

Patch works! Database needs to be updated after the patch is applied. Thanks so much =)

01:28:54 {master %} ~/websites/secular.dev$ drush updb
Forum_access  7003  Add support for 'comment' permission, #545916.
Do you wish to run all pending updates? (y/n): y
Performed update: forum_access_update_7003                           [ok]
'all' cache was cleared in self                                      [success]
Finished performing updates.

Re #71 - can you explain what exactly do you want the test(s) to contain? There are currently no explicit tests for view this forum, post in this forum, edit posts, delete posts permission so it would be the first. Test for Forum functionality (with FA and ACL) has been modified to account for this new permission already.

Attached is the screens for access control before and with the patch applied.

Can you explain what do you mean with "Please preserve the coding style: things that are aligned should remain aligned when a new (longer) item is inserted."?

There are currently no explicit tests for view this forum, post in this forum, edit posts, delete posts permission so it would be the first.

I'm not sure how you come to that conclusion — just look for comments like // Check whether we can create a topic., the createForumCommentWithText() method, and all the others. AFAIK we have full test coverage in the existing tests, and if we can separately allow posting topics and comments, then we need to test two additional combinations.

Thank you for the screenshots:
BEFORE:

AFTER:

Looks good except for a minor issue in the help text:

+++ b/forum_access.admin.inc
@@ -141,7 +141,7 @@ function _forum_access_forum_permissions_form($is_container) {
                               t('the !create_forum_content (and similar) permissions <strong>AND <em>Post</em></strong> to be able to create forum content, and', $variables) . '</li><li>' .
-                              t('the !post_comments (and optionally !skip_comment_approval) permission AND <em>Post</em> to be able to post comments/replies;', $variables) . '</li><li>' .
+                              t('the !post_comments (and optionally !skip_comment_approval) permission AND <em>Comment on posts</em> to be able to post comments/replies;', $variables) . '</li><li>' .
                               t('the !edit_own_forum_content or !edit_any_forum_content (and similar) permissions (<strong>OR <em>Edit</em></strong>) can be added if desired, <strong>plus</strong>', $variables) . '</li><li>' .

Please replace AND <em>Comment on posts</em> with <strong>AND <em>Comment</em></strong>. "Comment" stands on its own now and should be formatted like "Post".

Can you explain what do you mean with "Please preserve the coding style: things that are aligned should remain aligned when a new (longer) item is inserted."?

Here's an example:

+++ b/forum_access.admin.inc
@@ -248,6 +248,7 @@ function _forum_access_forum_grants_form(&$form_state, $is_container, $settings)
     $cols = array(
       'view'   => t('View this forum'),
       'create' => t('Post in this forum'),
+      'comment_create' => t('Comment on posts'),
       'update' => t('Edit posts'),
       'delete' => t('Delete posts'),
     );
@@ -598,7 +599,7 @@ function _forum_access_form_submit($form, &$form_state) {

The arrow operators used to line up and they should continue to line up. Whether you do that or not is a matter of personal preference, but if existing code is aligned, then you should not break the alignment.

What did you do with #41?

I absolutely need this functionality so I applied patch in #69.

Initially, trying to edit a forum (/admin/structure/forum/edit/forum/XXX) I've received the following:

Notice: Undefined property: stdClass::$grant_comment_create in _forum_access_get_settings() (line 771 of /var/www/mysite/sites/all/modules/contrib/forum_access/forum_access.admin.inc).

then, when I tried to add "comment on posts" permission and save the forum settings, I received:

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'grant_comment_create' in 'field list': INSERT INTO {forum_access} (tid, rid, grant_view, grant_update, grant_comment_create, grant_delete, grant_create, priority) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7), (:db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15), (:db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20, :db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23), (:db_insert_placeholder_24, :db_insert_placeholder_25, :db_insert_placeholder_26, :db_insert_placeholder_27, :db_insert_placeholder_28, :db_insert_placeholder_29, :db_insert_placeholder_30, :db_insert_placeholder_31); Array ( [:db_insert_placeholder_0] => 280 [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => 0 [:db_insert_placeholder_6] => 0 [:db_insert_placeholder_7] => 0 [:db_insert_placeholder_8] => 280 [:db_insert_placeholder_9] => 2 [:db_insert_placeholder_10] => 1 [:db_insert_placeholder_11] => 0 [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => 0 [:db_insert_placeholder_14] => 0 [:db_insert_placeholder_15] => 0 [:db_insert_placeholder_16] => 280 [:db_insert_placeholder_17] => 3 [:db_insert_placeholder_18] => 0 [:db_insert_placeholder_19] => 0 [:db_insert_placeholder_20] => 1 [:db_insert_placeholder_21] => 0 [:db_insert_placeholder_22] => 0 [:db_insert_placeholder_23] => 0 [:db_insert_placeholder_24] => 280 [:db_insert_placeholder_25] => 4 [:db_insert_placeholder_26] => 0 [:db_insert_placeholder_27] => 0 [:db_insert_placeholder_28] => 0 [:db_insert_placeholder_29] => 0 [:db_insert_placeholder_30] => 0 [:db_insert_placeholder_31] => 0 ) in _forum_access_form_submit() (line 636 of /var/www/mysite/sites/all/modules/contrib/forum_access/forum_access.admin.inc).

So I manually had to create the 'grant_comment_create' column in 'forum_access' table and then all works fine: I can confirm that the patch does correctly its job

Please, add the missing table update and then commit this (every other forum out there has this functionality!)

Thank you very much

Attached patch takes care of the issues mentioned in #83 (help text formatting and aligning).

If you are using this patch, make sure to run database updates!

Re #41 - I could use some help with separating out the functionality in a sensible matter so that comment permission could be set per forum. It's the UI part that is the most complex as there is already a lot to configure a forum.

I can confirm that:

Patch provided in #85 works great!

It applies cleanly on latest dev, and hook_update adds correctly new column on 'forum_access' table.

Again, please commit this!

Thank you very much

I still see no test coverage of the new functionality.

From #85:

Attached patch takes care of the issues mentioned in #83 (help text formatting and aligning).

It has not addressed the other issues in #83.

For what it's worth, the patch in #85 appears to work as expected for me, as well. I can set post / comment permissions separately by role, for each forum, and the permissions appear to function properly when I test posting/commenting for users in different roles.

I can confirm patch #85 works perfectly!

I applied the patch #85, works good.

Have successfully used the patch in #85. just to comment that the code alignment change requested in #83 is against current Drupal coding standards, which is probably why it was changed.