Re: 1.2 Proposal: Finish contrib.comments Moderation

[Waylan Limberg]

Sigh! I guess I sent this out a little prematurely.

On Wed, Aug 12, 2009 at 3:50 PM, Waylan Limberg wrote:
[snip]
>
> 2. Implement ticket #11625 -- Add admin actions to the comments admin.
>
[snip]
>
> 3. Using a proxy model and custom manager, create a second admin
> instance which only lists comments in moderation and offer the
> same admin actions as in 2 above.
>
[snip]
>
> 4. Incorporate the existing views into the admin by extending the
> base get_urls() method to point to them.
>
[snip]
>
> The other piece that is missing IMO is a way to make those admin actions
> available on an individual comment. Some times, one actually needs to
> read the comment to know if it is spam or not.
[snip]

Actually, implementing option 4 would accomplish this. The fact is,
the existing (undocumented) list view is not needed in the admin as
option 2 or 3 would fill that need. Therefore, the only views that we
would need to map to admin urls would be the `approve` and `remove`
views. We just need a custom template for the add/change view which
adds the respective buttons next to delete, save, etc.

The common code between the admin actions and the approve & remove
views could be factored out into a couple utility functions which,
along with the proxy model with custom manager (from option 2) would
provide enough for some one to implement there own non-admin solution.
That is, if that is even a goal.

So, the question is, whether we go with option 2 or 3 (and add option
4), do we want to remove the existing undocumented views and templates
for listing and acting on the moderation queue? Or do we want to leave
them in (and undocumented) as an example of how it could be done? Of
course, I'm assuming we are not concerned about backward compatibility
as none of this has yet to be documented. However, if might be nice to
depreciate it first for those who dug into the code and are using it.


-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

1.2 Proposal: Finish contrib.comments Moderation

[Waylan Limberg]

Currently, contrib.comments has a very useful (and customizable) mechanism
for putting questionable comments into moderation. However, approving/
rejecting comments afterword is still unfinished. There is a set of
urls/views/templates which provide a decent way to do this, but it is
currently undocumented and therefore (as I understand it) still subject
to change. There are a number of different ways this could be addressed:

1. Document the existing code currently available.

Pros: May potentially work without admin app (untested by myself).

Cons: Requires way too much setup by the user IMO and although the
  templates look like admin pages, the urls clearly indicate
  that it is not part of the admin.

2. Implement ticket #11625 -- Add admin actions to the comments admin.

Pros: Simple - least amount of work.

Cons: Getting a list of comments in moderation is unintuitive
  (requires user to select the "is_public==False" list filter
  on the admin page).

3. Using a proxy model and custom manager, create a second admin
instance which only lists comments in moderation and offer the
same admin actions as in 2 above.

Pros: Simple and more intuitive for the end user.

Cons: Moderation is on a separate admin page. I haven't actually
 tested that this works.

4. Incorporate the existing views into the admin by extending the
base get_urls() method to point to them.

Pros: Uses the existing Code. The new views will actually use
  admin urls. The views could potentially still be used outside
  an admin app.

Cons: Will require some way (custom templates perhaps) to include
  links to the new admin views.

Interestingly, options 2, 3, & 4 all rely on new features added in 1.1, which
may explain why they were not implemented before now.

Personally, I'm in favor of 2 (it is my ticket and patch), although 3 may
be a nice addition which could always be added later. That said, I do see
the attractiveness of 4, although I am unsure of the amout of code we can
reuse or the amount of work involved in that option. Any input on these?

The other piece that is missing IMO is a way to make those admin actions
available on an individual comment. Some times, one actually needs to
read the comment to know if it is spam or not. But, reading the comment,
then going back to the list view, selecting the appropriate comment
from the list and then selecting the admin action seems like a little
much. True, the user could set `is_removed` to `True` and save or delete the
comment, but then the appropriate moderation signal is never sent and
any custom (perhaps trainable) moderation system has no way of getting
feedback.

Of course, there is no way of doing this last bit now with the existing
undocumented code, and it should probably be a separate proposal for a
general admin feature, but I included it here in relation to comments
for completeness sake.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---