469730 - Per-post statuses applied to parent twice, skipping the actual post

Status: VERIFIED FIXED

(support.mozilla.org :: Forum, task)

Description

[E. Cooper [:ecooper]]

Attachment: Sets threadId for comment using $qId instead of $thread_info

This was pointed out by Cww to me inadvertently. It seems actual comments weren't getting their individual thread statuses set properly. Instead, the status was being applied to the parent twice. Thread statuses were being applied correctly.

I've attached a patch for this. Can we squeeze it into 0.8?

Comment 1

[E. Cooper [:ecooper]]

After a brief chat in #sumodev, it was decided statuses are supposed to have precedence over one another (so a request for more information doesn't reset the thread status if a solution has already been proposed). So, this is going to need a new patch.

A couple of pref will probably be added to allow for statuses and their weight to be changed via the admin panel.

Comment 2

[E. Cooper [:ecooper]]

Due to the size of the coming patch, I might push this back to the next milestone so it can get proper testing.

Or we can split this bug into two separate bugs, with comment 1 getting its own bug.

Comment 3

[[:Cww]]

Can we just have per-post statuses in 0.9?  Then when we do metrics, I can do an intensive but doable query to find out what the proper status should be and work from there.

The weighting and stuff will make the querying easier and fix other issues but if it's going to push the per-post stuff back, I'd rather have the two split.

Comment 4

[E. Cooper [:ecooper]]

(In reply to comment #3)
> Can we just have per-post statuses in 0.9?  Then when we do metrics, I can do
> an intensive but doable query to find out what the proper status should be and
> work from there.
> 
> The weighting and stuff will make the querying easier and fix other issues but
> if it's going to push the per-post stuff back, I'd rather have the two split.

It will land tonight then.

Comment 5

[E. Cooper [:ecooper]]

With the delayed freeze, the full patch will be landing.

This patch fixes the original bug, comment 1, and a few other odds and ends related to thread statuses. Namely, everything has been moved to preference-based management. That is, specifying which forum the dropdown shows up in, adding and removing statuses and their labels, etc. These can be found under admin->forums and the defaults are the current settings on production.

"Weighting" (so, r doesn't override p) is defined by order of values in the preferences. 

The "force" preference isn't implemented, and is part of bug 468613. The dropdown was moved below the textarea as per bug 468613, however.    	

Patch in r22343/r22344 and weighting turned on in r22346/r22347.

This can be verified once the preferences show up in https://support-stage.mozilla.org/tiki-admin.php?locale=en-US&page=forums

Comment 6

[[:Cww]]

Couldn't get staging to work so I verified it on sumotools.  Plus that way I can query the DB live and watch the statuses change.

Works like a charm, you're awesome!

Comment 7

[[:Cww]]

On the other hand, I have no idea how the panel works because you have o listed as a cannot be in this box but then it's in this box under "Special forum thread status values (comma-separated, single character, cannot be n, a, h, s, o, or l)"

I'm confused but the BEHAVIOR is what we want so I assume if I don't touch that part everyone's happy.

Comment 8

[E. Cooper [:ecooper]]

It's a "0". It just looks like a "o". :)

(In reply to comment #7)
> On the other hand, I have no idea how the panel works because you have o listed
> as a cannot be in this box but then it's in this box under "Special forum
> thread status values (comma-separated, single character, cannot be n, a, h, s,
> o, or l)"
> 
> I'm confused but the BEHAVIOR is what we want so I assume if I don't touch that
> part everyone's happy.