Feature Proposal: It would be more flexible to have the option for a descending table sort in the ActionTrackerPlugin

Motivation

By using a custom attribute like 'priority' I am really missing the option to sort the action table descending.

Description and Documentation

Since it is possible to sort action table columns, it would be more flexible to extend it with ascending and descending sorting. Currently it is always ascending.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: SvenHess - 18 Feb 2010

Discussion

Just now I have noticed the attribute "reverse" which provides exactly the feature I've described above. I have found it in the change history. It is implemented since January 2009, but seems too unimportant to mention it in the documentation. So no action required here.

-- SvenHess - 19 Feb 2010

For the record

Our process does not require that you raise feature proposals unless

• The proposal concerns core or default plugins
• The proposal changes the way the core/plugins work seen either from the end user, or the programming API.

Bug fixing, core improvements for stability, security, performance, maintainability etc can be done on a simple bug item.

And for none-default extensions you look at the policy for the plugin

If it is feel free to modify, you can go ahead but you should still consider the users and especially the original author or current maintainer before you change the behaviour of an extension.

If it is a Coordinate With Author you must coordinate with the author before altering an extension. In this case Crawford.

We do not raise feature proposals for that. Each extensions has a topic in Development web with same name as the extension and this is the place to suggest larger code changes. And else simply raise an Item in task web and set it to waiting for the author of the extension. Maybe pop him an email or say hello to him on IRC to put his attention on your proposed change.

Most authors are OK wise enough to accept that other people are fixing plain and simple code bugs.

-- KennethLavrsen - 19 Feb 2010

Thanks Kenneth. So in case I am going to fix an extension bug or improve a plugin which has a 'feel free to modify' licence, I can do it on my own, publish my changes, commit them to svn and announce it somehow?

-- SvenHess - 22 Feb 2010

Yes. the only thing I ask is that the unit tests still pass when you have finished.

-- CrawfordCurrie - 22 Feb 2010

Okay. And where should it be announced?

-- SvenHess - 22 Feb 2010

The best way to announce a fix in a plugin is to release a new version.

The normal way to handle plugin once you have OK from author is

• Raise a bug item in Foswiki Task web
• Fix the problem or add the improvement.
• Remember that plugins are used by users that run 1.0.9 or earlier. Noone runs production sites from trunk. So please test the extension also in Release01x00 branch. You can pseudo-install extensions from trunk to a release branch. Or you can build a release package and install it on a 1.0.9 by applying the zip or tgz like a real user would do.
• If the extension comes with unit tests make sure they still pass. It may be difficult to write new unit tests but fixing those that are there is not hard.
• Check-in the fix on SVN
• Remember to uprev the extension. Remember to update the change history in the Extension topic
• Set the bug closed (only core and default extensions go to WaitingForRelease
• Release the extension unless someone else is also in the process of updating the extension
• Note: BuildContrib is your friend

-- KennethLavrsen - 22 Feb 2010

A minor feature improvement is usually announced in ExtensionNews, and you can blog it at http://blog.foswiki.org if you think it's worth it.

-- CrawfordCurrie - 23 Feb 2010