#9288: Improved commenting infrastructure
----------------------------+-----------------------------------------------
Reporter: timo | Owner: timo
Type: PLIP | Status: reopened
Priority: minor | Milestone: 4.1
Component: Infrastructure | Resolution:
Keywords: |
----------------------------+-----------------------------------------------
Comment(by timo):
Replying to [comment:49 cah190]:
> (In [46018]) Review for PLIP 9288. Refs #9288
>- The plone.app.discussion egg depends on a uuid egg that does not
>appear to be used directly anywhere.
pad uses plone.app.uuid (which depends on plone.uuid) to generate unique
ids in Plone. There is just no need to call the code directly. There is a
separate PLIP for the uuid package.
>- The plone.app.discussion egg also depends on
>collective.autopermission; is this necessary?
This is necessary for Plone 3, it can be removed once pad is merged into
Plone 4.x.
>- I received one error running plone.app.discussion tests: importing a
>Duplicate profile ID for Products.CMFUid:default. I am not sure this is
>plone.app.discussion's fault, but may need to be looked at if we decide
>to merge. Otherwise all plone.app.discussion tests pass and have
>reasonable coverage.
I don't think this is related to pad.
>- Installing plone.app.discusion results in a deprecation warning "An
>icon for the 'controlpanel/discussion' action is being added to the
>action icons tool. The action icons tool has been deprecated and will be
>removed in Plone 5. You should register action icons directly on the
>action now, using the 'icon_expr' setting."
Fixed.
>- Replying to comments appears to be impossible when JavaScript is
>disabled. Only new top-level comments can be left.
This was a concious design decision. We move the comment form around
instead of loading it with AJAX-calls on request. I think it is sufficient
if the basic functionality works if Javascript is disabled.
>- Users who are only Authenticated (i.e. not having the Member role)
>cannot leave comments, even if they log in using the "log in to leave
>comments" button.
Fixed.
>- Deleting a comment also deletes all replies. I expected a placeholder
>or empty space with the replies being preserved. Perhaps we need a way
>to blank out a comment that preserves replies?
This is the default behavior of the old commenting system. Though, I agree
that a placeholder would be a nice feature (that can be implemented in the
future).
>- Allowing anonymous comments is only available as a global toggle for a
>site. I can see people wanting to enable it per type or even per object
>as the commenting functionality is controlled.
I know, I have tons of feature request waiting to be implemented. :)
>- Changing workflow on the comments to enable moderation is a bit
>strange. It seems like the configlet should be able to do this.
Done.
>- The "Globally enable comments" setting in the configlet is somewhat
>confusing. Perhaps it would make sense to reverse the checkbox and make
>it a global killswitch instead? Or even just get rid of the global
>toggle entirely.
This has been discussed on the fw/ui mailinglist. Commenting should be
disabled by default. Though, I agree that this setting is confusing when
using pad as an add-on product.
>- The moderation seems reasonable, though it's strange to allow Managers
>to reply to unmoderated comments, which can then be deleted, taking out
>the replies in the process.
So you want to disallow Managers to reply to unmoderated comments?
>- There should be a way to whitelist users/roles/groups so their
>comments do not require approval. Only requiring moderation for
>anonymous comments is a typical workflow.
New feature. Beyond the scope of the plip.
>- The viewlet for the commenting UI does not appear in
>@@manage-viewlets, which is unexpected.
It does. It just does not appear on the portal root (because it is not
registered for portal root).
>- Why is the Moderate Comments user action always visible, even when
>moderation is disabled?
Fixed
>- catalog.py has a Todo item in the effective method.
Fixed.
>- conversation.py has an XXX item about removing child comments that
>should be addressed.
I have to ask Lennart Regebro about this. He added this XXX.
>- browser/comments.py has an XXX comment that should probably be a BBB
>comment instead.
Fixed.
>I do not like seeing the "Moderate Comments" so highly visible in the
>user actions when moderation is disabled by default and requires
>changing workflows to enable. It seems like the configlet should be
>able to change moderation settings, perhaps by having a three-state
>control that allows moderation to be disabled, enabled with standard
>workflow, or enabled with custom workflow. When disabling or enabling
>with standard workflow the configlet should change the workflow for
>comments automatically. The enabled options should make the moderation
>action visible. And the enabled with custom workflow options should
>probably activate some helpful text in the configlet suggesting the
>workflow be set manually.
This has been fixed. Please take a look at the current implementation and
let me know what you think.
--
Ticket URL: <http://dev.plone.org/plone/ticket/9288#comment:56>
Plone <http://plone.org>
Plone Content Management System
_______________________________________________
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories
