You should add a new column to columns_api rather than extend the functionality of an existing one. The last update date and last update author are completely different things and as such should both be treated independently. Some users may want to know the last update date, but doesn't necessarily need to know who made the update.

I think it's a bit misleading to use the word "updated" and yet ignore other forms of update (changing the priority, etc). I think it'd be better to check the last user_id for the history of a given bug so it truly does represent the last updater.

Can you please justify your usage of the SQL "COALESCE" function? It doesn't look right to me. Is it supported by AdoDB for the common databases (MySQL, PostgreSQL, MSSQL, Oracle, SQLite etc)? I thought that the SQL standard required databases to return a value of NULL from MAX(column) where "column" is from a table with no matching rows. In which case, can't we just check (with PHP) that the result is NULL or an integer?

I've reviewed your patch and have made a number of changes/corrections. Attached in issue10539_v1.diff is the results of my work.

I had to make the following changes:

1) The SQL query in bug_get_last_bugnote_reporter is ugly. In general, when you see nested SQL queries - it's a good sign the query is bad and can be replaced with a much simpler alternative. In this case, we can just use the ORDER BY statement and remove all the complex stuff you had in your original query.

2) I've removed the enable_lastbugnote* options as I couldn't justify why administrators would want to prevent users from viewing those columns if they wanted to do so. I agree that this functionality could be useful and I'd be happy to add it if it can be applied to all columns (including those added by plugins, custom fields, etc) consistently.

3) The strings used in print_column_title_lastbugnote* were not added to lang/strings_english.txt - I've added them to my patch.

4) In print_column_last_bugnote_timestamp we should be comparing the result of bug_get_last_bugnote_timestamp with "false" rather than "null" - and the check should be !== instead of != to ensure that types are preserved in the check.

5) Adding the last bugnote reporter to the data shown in my_view_inc.php doesn't seem right to me. We're displaying the timestamp that the bug was last updated so I'd expect to see the name of the user who last edited the bug. The bug last modification time that is shown also factors in the bugnotes too. I've removed this data for now, but would be happy to add it back later if this matter is fixed.

6) Your patch had what appeared to be some remnants of other work in file_api.php so I've removed that. Seems it got into your patch by accident :)

Before merging into 1.3.x I'd still like these points addressed:

1) The last bugnote updater and timestamp columns should be sortable (ascending or descending order) like all other similar columns.

2) I'd like to see a new column listing the user that last modified the bug (including bugnotes in this check) so that we maintain consistency. We'd thus have a column for the timestamp of the last modification to a bug (and any child bugnotes) and the user who performed the modification. And we'd also have a column listing the timestamp of the last modification or addition to bugnotes attached to a bug. Of course, this column would also have the last bugnote reporter or editor listed as well.

About the points:
1) how do you make a column sortable? (example or point to start from will help)
2) multi-value columns? or make that much (last updater user + last modification timestamp + bugnote last modification timestamp)?