Skip to content
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.

Use "type" field to support configurable types of comments #9

Closed
hvorragend opened this issue Aug 5, 2011 · 1 comment
Closed

Use "type" field to support configurable types of comments #9

hvorragend opened this issue Aug 5, 2011 · 1 comment

Comments

@hvorragend
Copy link
Member

EZComments currently has a "type" field, but it cannot be configured.

If I remember correctly, the type field is used to distinguish between different comment types (e.g. normal comments, or trackback comments).

Currently it's not possible to add custom types.

Use cases: I currently run 2 EZComments installations in parallel, to handle different types of comments. Using the type field, I could do with one install.

Excellent module otherwise - thanks.

stefaan
Attachments
Change History
comment:1 Changed 3 years ago by Stefaan

Summary changed from Use "type" field to support multiple types of comments to Use "type" field to support configurable types of comments

comment:2 Changed 3 years ago by quan

Milestone set to EZComments 2.0

I do not know for what use case the type field was introduced once - perhaps you can explain how YOU would use the type fields?
comment:3 Changed 2 years ago by StefaanV

My current use case:

I have about 25 sections in my website, with different types of content. Let's take two examples:

  1. one section contains user blogs
  2. one section contains factual articles

This leads to two type of comments:

  1. Blogs: typical comments are permanent - they are part of the discussion, offer additional info. Here it's important to keep the comments

  2. articles: typical comments point out factual errors. Typical workflow: comments are processed, corrections are applied to article, comments are deleted.

To make it easier for editors, I've set up two EZComments systems in parallel: one for the permanent comments, one for the "errors and omissions" (here editors have permsissions to delete comments).

Other use case (probably more widely relevant):
I have about 20 different publication types in pagesetter. These include News, Blogs, etc.

As far as I can tell, EZComments can only classify these as "pagesetter" EZComments (no distinction between publication type). Besides the distinction between comment types mentioned above, I think the following use cases would be really useful:

  1. Allow Editors to manage comments for a specific module or pagesetter publication( e.g. News editor can moderate News comments, "Recipes" editor can moderate recipe comments...

  2. Allow Bloggers to manage comments on their own blog - so bloggers can moderate comments on their own posts.

I see pagesetter/pagemaster as the main module to benefit for this, but I can image it would be useful in photo gallery modules as well (people could manage ezcomments for "their" gallery).

Please correct me if I'm wrong, but I think at this moment EZComments can only distinguish between modules. So my idea was to use the "type" field as an easy way to distinguish between whatever is necessary - I can just add the type field whenever I call the hook.

Hope this makes sense :-)

Practically, it only requires minor modifications to the code.

The "type" field exists, but is currently limited to 2 values (hardcoded). Simply removing those hardcoded values would work already.
optionally, Providing a configuration option allowing admins to enter a list of values would work as well,
optionally, providing a filter in the admin list to only show a specific type would be nice as well.
optionally, Including the type field in the security scheme would make it complete. 

thanks,

stefaan

@paustian
Copy link
Collaborator

paustian commented May 4, 2020

Again this would involve considerable work. The request is 9 years old. If someone is still interested, please let me know.

@paustian paustian closed this as completed May 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants