Posted by NancyDru on September 21, 2009 at 3:57pm
6 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | dblog.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | NancyDru |
| Status: | needs work |
| Issue tags: | Usability |
Issue Summary
- '#description' => t('This will permanently remove the log messages from the database.'),
+ '#description' => t('This will permanently remove ALL log messages from the database, regardless of the current filter.'),
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| dblog_clear.patch | 748 bytes | Idle | Failed: Failed to apply patch. | View details | Re-test |
Comments
#1
added tags
#2
The last submitted patch failed testing.
#3
Sure wish Tortoise would create proper patches...
#4
my usability opinion would be:
1- a whole (dangerous) fieldset to hold a single button?
2- users allowed to access reports are also allowed to get ride of them?
R/1) provide two buttons, "Clear old messages" and "Clear ALL messages"
the first one, would be configurable for how long would be the "old" window frame, and that configuration might show up as part of the description, kind of
"Clear old message will permanently remove ... beyond the %time_window" making '%time_window' evaluate to "last half hour" / "3 hours and 15 minutes" / etc (I can provide the "format_minutes" function for this kind of messages)
R/2) before rendering/submitting the form check for user_access on 'administer site configuration' as well
meaning that for log clearance users will need both, to be able to "access" and also to "administer" log history
#5
1. I didn't add the field set, it's already in core. But I tend to agree that it is poorly implemented. I much prefer how we do it in Util.
2. That's how it's coded in core already. I'm not crazy about this either because I have a site where sub-admins occasionally look at the log, but they never had the capability to delete messages before.
R/1. "Clear filtered" not "Clear old" - let a time filter take care of that.
R/2. That would take care of my use case, I think. I would still rather see a "clear log" permission to be more proactive.
#6
@#5
a) yes, I know, and I agree it shouldn't be there by default, maybe enabling it at
admin/config/development/loggingb) when I want to be fast, I just want to get the last 10 top logs, or the last 1 hour logs, that is the job for a straightforward link, not a filter and then a clear button
c) nevertheless, a "Clear filtered" button would be very desirable
I was just saying that the core's fieldset is some... misplaced
it is also dangerous
and the most important, accessing the logs is not permission enough to be able to drop them
#7
+1
Also, when logs *are* cleared, a log entry should be generated that notes this action.
#8
Looks like this will be D8, unless someone can bump it into D7.
Based on that and commends in #6 and #7, marking needs work...
#9
#3: dblog_clear.patch queued for re-testing.
#10
The last submitted patch, dblog_clear.patch, failed testing.
#11
No screenshot to review