• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Note: This is not user facing and probably does not need to go through the LEP process. However, we're using the template.

Also note: the process of nominating spam depends on this.

Hide Spam

As a Launchpad adminstrator (LOSAs + ?)
I want to be able to easily hide, and possibly delete, spam
so that removing spam takes much less time and energy
(so that LOSAs have more time to do other useful things and maybe spam is dealt with in a more timely way)

This feature is separate from allowing users to nominate spam but it is intended that the work for this project will support and be integrated into the other effort, when it is started.

It is a part of the response to bug 45419. This part is deemed separable, and a higher priority, than the nomination work.

I suspect LOSAs would be thrilled if CHR workers could perform these actions. I don't see why they shouldn't.

Rationale

The LOSAs have identified bug 45419 as one of their most painful Launchpad issues July, 2010. We understand that to be primarily about the ability to more easily hide spam. Right now they must use SQL directly.

Stakeholders

• LOSAs
• (any other Launchpad adminstrators)

Constraints

• Provide a single button for only Launchpad administrators to hide spam once it has been identified.

• Spam items are hidden from visibility and from searches.
• Provide an undo mechanism for when mistakes are made.
• Corollary: Allow administrators to see hidden spam.

• Support the process of nominating spam.

• Expected corollary: Provide a uniform API for hiding and revealing.
• Do not break cached page snippets; ideally, do not make it harder to cache snippets, but considering that is quite possibly neither appropriate nor necessary at this stage.
• Provide the ability to gradually roll out this functionality to different types of Launchpad objects. We will start with bug messages, question messages, and code review messages.
• Corollary: Provide an easy path for adding this functionality to future objects, recognizing that different objects may have different "hiding" mechanisms.

Unnecessary Desires

These are called out as things that are *not* constraints for this proposal, even though they might be desirable.

• As mentioned, we will not implement the process of nominating spam at this time.

• We will not provide a mechanism for permanently deleting spam. We might eventually have a garbage collector permanently clean out old spam.
• We will not provide a mechanism for identifying users who generate lots of spam. We might identify a hookpoint for the future.
• We will not provide a mechanism for identifying who hid an item and when.

Subfeatures

None, but Foundations/Proposals/NominateSpam is a subsequent feature.

Workflows

Hide

• Administrator identifies spam item.
• Administrator clicks button next to item labeled "Hide"
• Administrator sees item grayed-out with text indicating item is hidden from users. Button "Hide" is gone. Button "Reveal" is present.
• (Subsequently, non-adminstrator users no longer see this item, and it is not a part of search results)

Reveal

• Administrator identifies grayed-out item that was incorrectly hidden.
• Administrator clicks button next to item labeled "Reveal"
• Administrator sees item no longer grayed out. Button "Reveal" is gone. Button "Hide" is present.
• (Subsequently, non-adminstrator now see this item again, normally.)

Success

We will know we are done when the system is built for at least three kinds of Launchpad objects; and it is deployed and the LOSAs can use it.

Thoughts?

In many ways, this project is really establishing a pattern: it will likely not generate many reusable elements.

I think we ought to start with an interface to encourage uniformity. Something like this:

class IHidable(Interface):

• hidden = zope.schema.Bool(...)

Here's an example implementation for setting up this functionality for a certain type.

1. Add a "hidden" column to the pertinent table.
2. Expose in Storm.
3. Have the object implement IHidable or make an adapter to it.
4. Expose necessary methods/attributes in ZCML so anyone can see "visible" and only the proper users can change it.
5. Expose attribute in webservice.
6. Make appropriate pages showing the hidable items conditionally show hide/reveal buttons depending on whether the user has the ability to change the value. We hopefully can have reusable JS to switch buttons between hide and reveal, send webservice requests, and gray-out divs if something is hidden.
7. Make pages and searches not show hidden items for non-admin users.

Of that list, I see three reusable elements:

• a pattern,
• an interface, and

• maybe some JavaScript.

I've tried to think about this generically and to find some valuable automation, but upon reflection I really don't see any. I'd be happy to hear otherwise.

This does not play to Foundations' strengths right now. Maris is our JavaScript developer, and he has many obligations because of his build engineer position. When he is not working on that, I would prefer to have him work on client-side performance-related tasks.

Stub comment: Maybe could make make handling comments generic.

Curtis: I do not think this is a LOSA job. Data integrity and community interaction is the responsability of ~registry (launchpad engineers and some extra people) I wanted to add a two flags, is_spam and is_visible to IMessage. logged in users would see button (This is spam) when their mouse was hovering over any IMessage decendent like IBugComment. Choosing the button work change the message to indicate someone has flag the message as spam, the button changes to (This is not spam). There is a queue where ~registry can see all messages flagged as spam. They can unselect the is_visible to hide the message. ~registry members can view any message (bugs/1234/+comment/4) and see an link to edit the message. The member can redact personal information so that the crucial information remains visible.