I agree that the concept of sticky issues is useful. Following are my comments:

1. Having it per user will over complicates things. I would say we should have it on a system level, and have an access level that is required to make an issue sticky or normal.

2. The user can use the monitoring feature and associated filtering (which is currently only available through My View) as an alternative for personalised sticky issues.

3. The API that retrieves the filtered rows should support switching sticky issues ON or OFF as a parameter. In my opinion, it should be ON in the View Issues page, but OFF when retrieving the rows for My Views page.

4. If some users do not want to have sticky issues, then this can be achieved by disabling sticky issues support in their own preferences. Although I would rather only add this if we find out it is really needed.

This will be very usefull in a support situation - think global tickets.

1. Agreed. I assume by system level, you mean per project.
2. Would this be a config option? I assume so, with a default set to No support for disabling sticky issues.

I've commited some changes for sticky issues.

It's a quick and dirty solution and for now everyone can set/unset an issue sticky.

To set or unset an issue sticky you have to select the issue/s and use the mass bug manipulation dropdown.

This patch adds a new column to the bug table.

The committed changes to filter_api.php have messed up pagination completely on the "View Issues" page.

Upps, your are right, it's fixed now.

Access level for sticky issues added
Sticky issues can be disabled by filter

Is this done now?

Without translations, but it works. ;->

See 0005042

One week of testing and no errors.