Closed
Bug 724879
Opened 14 years ago
Closed 14 years ago
Migrations for 'search.reindex' permission
Categories
(support.mozilla.org :: Search, defect, P1)
support.mozilla.org
Search
Tracking
(Not tracked)
VERIFIED
FIXED
2012-02-28
People
(Reporter: rrosario, Assigned: willkg)
Details
(Whiteboard: u=dev c=search s=2012.4 p=1)
Missed this and only superusers can access search admin page.
| Assignee | ||
Comment 1•14 years ago
|
||
This needs to get done ASAP otherwise superusers are the only ones that can do anything indexing related.
Making it a P1.
Priority: -- → P1
| Reporter | ||
Comment 2•14 years ago
|
||
We should land this ASAP (next week).
Assignee: nobody → rrosario
Target Milestone: --- → 2012-02-21
| Reporter | ||
Updated•14 years ago
|
Assignee: rrosario → willkg
| Assignee | ||
Comment 3•14 years ago
|
||
I've got this so far:
SET @ct = (SELECT id from django_content_type WHERE app_label='search' and name='index');
INSERT INTO auth_permission (name, content_type_id, codename) values
('Can reindex elastic search', @ct, 'reindex');
But the @ct is probably wrong since the search app doesn't have any models let alone one named 'index'.
Seems like I need to add a 'fake' app model to django_content_type. Do we do that sort of thing? If so, is there anything I should know?
| Assignee | ||
Comment 4•14 years ago
|
||
I'm going to add a LogRecord model, add some code to log reindexing things, and add some code to view the log. Then I'll key the permission off of that.
| Assignee | ||
Comment 5•14 years ago
|
||
https://github.com/mozilla/kitsune/pull/497
As a side note, this bug ballooned from it's original 1 pter "do a migration" to a slightly longer 2 pter "write the migration and a new model and some code to log reindexing runs". That coupled with my doing a bunch of these things for the first time made it take longer than it would typically.
| Assignee | ||
Comment 6•14 years ago
|
||
Landed in master: in https://github.com/mozilla/kitsune/commit/c9eef4571441c1485536cd9fd9caa6f6e57e594a
QA:
There are two things here:
1. A non-superuser user that doesn't have the record.reindex permission can't see the search admin page. Adding that permission allows them to see the search admin page.
2. When you run a reindexing from the search admin page, the reindexing history should show a new record with which index you reindexed to and the start time. Finishing reindexing updates that record with the end time. You might need to refresh the page to get that, though.
Item 1 is useful to QA. Item 2 isn't very--it's just admin hoo-hah and if it doesn't work quite right, it's not a big deal.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: 2012-02-21 → 2012-02-28
Comment 7•14 years ago
|
||
I had a superuser add the permission: search|record| Can run a full reindexing to a user
The non-superuser logged in and went to : https://support.allizom.org/admin/search
expected: admin search page
actual: admin sign in page displays
Is this the correct permission & Admin search page link?
| Assignee | ||
Comment 8•14 years ago
|
||
Does the non-superuser have access to any admin pages? If so, then the non-superuser should be able to access the admin, but _not_ access the search admin page. The search admin page will show an "Access denied" message.
I can't really tell what you did, but maybe that helps?
Comment 9•14 years ago
|
||
(In reply to Will Kahn-Greene [:willkg] from comment #8)
> Does the non-superuser have access to any admin pages?
If not, make sure they have Staff checked as well.
Comment 10•14 years ago
|
||
Verified user with staff permission + individual search permission can view /admin/search
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•