recent/aged/username/hostname filters for log entries

then..
do you encourage me to go for it?
I wouldn't like to spend time cleaning code if it won't be even considered for possible commit

BTW, wouldn't be the same to filter on anything than clearing the log, when I have some tricky bug dumping errors into my logs I use to clear all logs to see what's new, and I'm talking about the same message, so it wouldn't be possible to filter.. unless having a date/time filter I guess
Nevertheless, on development I prefer to delete than filter logs, that's why I use those criterias
which, by the way, aren't fixed, since the callback would handle any integer argument passed (it could have a textfield for the minutes or logs amount but would require a submit button then, I thought links are handier)

what for the "recent" and "old"? kind of quick-links to filter?
I could add that feature..

let me know if there is any change to get this features into this module and I will provide patches

PS: do you prefer patches against dev? being so decoupled it wouldn't be necessary right?

well, having filters for recent/old and a "clear" button makes the whole functionality of what I initially proposed
though, I made a module for recent/old

but... it needs a minor collaboration from dblog module
actually I made a home version which duplicated dblog functionality, but that wouldn't be necessary if dblog would have a hook for its filters

therefore, I provided a patch for Drupal 7.x-dev
do you think it would be on time?

would you give some feedback on #582622: provide hook for dblog_filters
see the screenshot and tell me if thats what you want

BTW recent/aged times are configurable, just an array with minutes amounts

the module dblog_time_filters
the screenshot dblog_time_filters.png

Features:
- optionally offers recent and/or aged filters
- times are configurable as shown in one of the screenshots
- optional integration with util module (otherwise makes its own settings page)

Important:
- I didn't like to duplicate dblog's behavior, thus a patch must be applied for this module to work
this patch is available for both D6 #582672: dblog support filters through a hook (6.x) and D7 #582622: provide hook for dblog_filters

Notes:
- the recent/aged filters appear before due to alphabetical order, changing the weight of the module would make them go bellow
- the "clear" button in the screenshot is from clear_log module bundled with util module
- I needed the "- None -" option for Firefox (not for Chrome), because couldn't unselect (Ctrl+click) the single select, I can with select having multiple="multiple" or multiple="false", but having no "multiple" attribute in FF2 doesn't allow me to unselect

1) I can mirror dblog's functions allowing hooks and use menu_alter to active mines instead. Would it be preferable?

2) no user filtering, but yes, it would be easy with the hooks

3) actually "-none-" is required, since non-multiple selects can't be unselected, same as drop down lists

PS: please, also review the D7 patch (it might get into code freeze)

the original intention of this post was to provide another module for the util package, but being more flexible and generalizing the use case, it doesn't makes sense to have util module as a dependency, since these modules stand by them self
nevertheless, I declared package=Util in case you like them

dblog_ext - provide hooks for dblog_filters
(the same what the patch does to dblog, thus mimics dblog)

dblog_clear - doesn't requires dblog_ext, but integrates really good with dblog_filters
(old log_clear in util package, making its name consistent with what it actually does)

dblog_filters - requires dblog_ext or the patch (available for D6 and D7)

dblog_time_filters - (pending date/time filter, but has recent/aged filter)
dblog_user_filter - (with autocompletion)
dblog_host_filter - (without autocompletion but support contains/starts/ends/exact matches)

three last modules relies on dblog_filters
and taking advantage of that they don't have to do much
as an example, I post bellow the WHOLE module

/**
 * Implementation of hook_log_filters_settings().
 */
function dblog_user_filter_log_filters_settings() {
  $settings['username'] = array(
    'title' => 'Username',
    'description'    => 'Filters by username with autocompletion.',
    //'page arguments' => array('dblog_user_filter_settings'),
    //'file'           => 'dblog_filters.user.admin.inc',
  );
  return $settings;
}

/**
 * Implementation of hook_log_filters() on behalf of dblog.
 */
function dblog_user_filter_log_filters() {
  if (!dblog_filters_is_enabled('username')) return array();
  
  $filters['username'] = array(
    'title' => t('Username'),
    'where' => "u.name = '%s'",
    'conjunction' => FALSE,
  );
  $filters['username']['widget'] = array(
    '#type' => 'textfield',
    '#autocomplete_path' => 'user/autocomplete',
    '#maxlength' => USERNAME_MAX_LENGTH,
    '#size' => 27, // fit the same with than <select>
  );

  return $filters;
}

shoot! didn't I uploaded the dblog_ext module already?
I already implemented a module to provide the required functionality without the D6 patch.
I though I posted it here, but seems like I forgot.

Now attaching it.
Note that this would be the alternative to the patch, so no patch would be required and dependent modules are incompatible with the ones relaying on the D6 patch.

Please forgive the coder's flags for now, I will clean up the code once functionality gets reviewed and approved by a couple of users.

PS: taking note about NOW() vs Unix timestamp. Nevertheless, the uploaded version dates from September 21, so the @TODO comment is still there.

I hit "Save" instead of "Attach", I shouldn't miss it twice..

modules attached at #13 are described at #9

thanks a lot for your detailed review

the TODO list would be:
1- the coder's flags (@#11)
2- change @TODO comment to document why PHP time over MySQL NOW (@#11)
3- settings form bug: array index doesn't match variable name (@#15)
4- feature: add "- None -" option to host filter (@#16)
5- usability: non-sense condition count($host_list) > 1 (@#16)
6- revamp user filter: use select list instead of autocomplete (@#17)

about the above list
5- I think I meant (but didn't do it) a select under certain threshold and a textfield if the count excedes the threshold (configurable threshold?). Note that the textfield might be used (configurable settings) to match starts/ends/contains/exact, nevertheless it might be implemented with autocompletion as well.
6- Are you sure about always having a select? It might be a huge select! I think it should be a select or autocomplete according to certain threshold (again: configurable threshold?)

6) If there is a log entry for every session opened/closed then the list of users would be as long as registered users exists in the site. am I wrong? am I missing something?
Yes I noticed you were looking realname support, but autocompletion would be the same than provided by core every where user autocompletion is used. right?

5) I never though about it. I implemented it because it was requested in some other issue marked as "won't fix". I though it would had some use case. But I think you are right.

removed double post

(I couldn't remove #24, so removing #23 instead, http://drupal.org/comment/edit/2128522 keeps giving me 503 Service Unavailable)

truly right

5) multi-sites won't have too much hostnames, it should be a select

6) users would be limited by the watchdog limit.

thanks a lot for sticking on this.

Note:
for users that might intend to test these modules, they are in acceptable condition
I encourage testing them and leave feedback
read the current TODO list at #19

PS: I'll bring another release as soon as I get ride of a couple of deadlines

for the updated TODO list of these modules refer to #623740: dblog_ext/dblog_filters TODO list