Closed
Bug 424617
Opened 16 years ago
Closed 16 years ago
List of threads I've posted in
Categories
(support.mozilla.org :: Forum, task)
support.mozilla.org
Forum
Tracking
(Not tracked)
VERIFIED
FIXED
0.7
People
(Reporter: jason.barnabe, Assigned: jason.barnabe)
Details
(Whiteboard: tiki_fixed)
Attachments
(1 file, 2 obsolete files)
10.52 KB,
patch
|
nkoth
:
review+
|
Details | Diff | Splinter Review |
Having a list of threads a user has posted in would make it easier to follow up on suggestions. http://support.mozilla.com/tiki-my_tiki.php?locale=en-US provides this, but it has problems. -You don't get the info you would in a regular thread listing, like who posted last and when -It's not paginated. Some people have thousands of posts already.
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → jason_barnabe
Target Milestone: --- → 0.7
Assignee | ||
Comment 1•16 years ago
|
||
This introduces the concept of "filters". The filter controls appear at the bottom of thread listings. Users can choose "All posts" or "Containing posts by me". They can also choose the date options (Last 24 hours, etc.) that are currently in production. There's a special user value "_me" that shows the current user's posts. You can also put a user's name in, but there's no UI to do that.
Attachment #311306 -
Flags: review?(nelson)
Assignee | ||
Comment 2•16 years ago
|
||
I'd be interested to see how this performs on users with 1000s of posts before it goes live...
Assignee | ||
Comment 3•16 years ago
|
||
Unbitrotted the last patch. Also fixed a bug where the filter would stick when you went to the next page. There's still a bug where the number of pages in the pagination is wrong. This bug exists today for the date filter, so I'm fine putting this in without fixing it.
Attachment #311306 -
Attachment is obsolete: true
Attachment #314236 -
Flags: review?(nelson)
Attachment #311306 -
Flags: review?(nelson)
Comment 4•16 years ago
|
||
When I tried attachment 314236 [details] [diff] [review], it seems to take forever... and never ends. I think the IN subquery is not scalable.
Assignee | ||
Comment 5•16 years ago
|
||
You're right, I didn't notice because before I had a small dataset. It was running that subquery once for every row in the database! I thought SQL was smarter than that :) This new patch runs it once and generates a list of IDs, then uses that. I ran this against Bo in my test DB, who has 1700 posts and it came back quickly. Just to be safe, I limited the number of results returned to 1000.
Attachment #314236 -
Attachment is obsolete: true
Attachment #321345 -
Flags: review?(nelson)
Attachment #314236 -
Flags: review?(nelson)
Updated•16 years ago
|
Attachment #321345 -
Flags: review?(nelson) → review+
Assignee | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Whiteboard: tiki_triage nelson
Updated•15 years ago
|
Whiteboard: tiki_triage nelson → tiki_fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•