Development discussion for ChecklistPlugin

Wouldn't it be Nice If...

Idea	Who	Timestamp
Renaming a topic also renamed its corresponding ChecklistItemState topic.	SeanCMorgan	13 Aug 2008 - 11:26
Checklist had a "log" option that would set the date/time an item's state was changed (and by whom)	VickiBrown	09 Jun 2009 - 11:35

Discussions

-- DanielRohde - 27 Oct 2005

Is there a working example of this somewhere accessible?

-- AntonAylward - 28 Oct 2005

Sorry, but I don't have any open TWiki installation.

-- DanielRohde - 31 Oct 2005

I published the next release (v1.002) with some major bug fixes. See Bugs:Item808 for further details.

-- DanielRohde - 31 Oct 2005

Undocumented: This depends on SmiliesPlugin

-- AntonAylward - 31 Oct 2005

Thanks Daniel for contributing this Plugin

I made a few changes to the ChecklistPlugin topic, feel free to take it into the next release. Thanks for taking the time to measure the PluginBenchmarks numbers.

You bring many examples, but from the description it is not obvious how the checklists get rendered and how to change the state. Possibly add "you type" / "you get" illustrations? See example in RenderListPlugin.

-- PeterThoeny - 01 Nov 2005

Hi! The next release comes with some bug fixes and documentation improvements. Take a look at the Bugs:Item814 topic.

AntonAylward: The SmiliesPlugin dependency was documented in the Plugin Info section of the ChecklistPlugin topic.

PeterThoeny: Thanx, I have improved the docs.

-- DanielRohde - 01 Nov 2005

Hi again! Now all planned features are implemented. The published version (v1.004) is available in Subversion (all previous versions too).

-- DanielRohde - 01 Nov 2005

Daniel, please do a svn checkout before you update so that you don't overwrite other people's contributions.

-- AntonAylward - 01 Nov 2005

Anton, sorry, I have done a svn update and ignored your changes. The next release (v1.005) is published and incorporate your changes and fixes a major bug (I forgot unlock after topic save).

-- DanielRohde - 02 Nov 2005

I use mod_perl. When I check items as completed, I get different values for all of the smilies, every time I refresh, but cycling after three or four refreshes. Does this plugin work with mod_perl?

-- AnthonyDervish - 04 Nov 2005

Hi Anthony! I don't test it with mod_perl. I changed the context of two variables (resetDone, stateChangeDone). You can find a beta version in Subversion: svn checkout http://svn.twiki.org/svn/twiki/trunk/ChecklistPlugin

-- DanielRohde - 07 Nov 2005

Hi! I've fixed some bugs in the new release v1.007. I use the strict pragma now so it should works with mod_perl.

-- DanielRohde - 07 Nov 2005

I just tested this plugin with mod_perl and it does not work reliably.

I often click on the icon and nothing happens. Then I click on another icon then then suddenly the previous icon changes. I think this plugin needs more testing with mod_perl

-- KennethLavrsen - 05 Feb 2006

It also uses a deprecated handler.

-- KennethLavrsen - 05 Feb 2006

Hi Kenneth, there is a quick bug fix for your problem: try to add following line to the initDefaults() subroutine of ChecklistPlugin.pm:

%namedIds = ( );

And don't forget to restart Apache. The next release fixes this problem.

-- DanielRohde - 06 Feb 2006

Kenneth, which handler is deprecated? I think you mean endRenderingHandler but I need backward compatibility with Cairo (my production release) - any ideas to fix this problem?

-- DanielRohde - 06 Feb 2006

Hi again, I found a solution for the deprecated handler problem: HandlingCairoDakarPluginDifferences

The next release comes with two fixes

-- DanielRohde - 06 Feb 2006

The published release 1.014 fixes two bugs:

• mod_perl bug (forgot hash initialization)
• fixed deprecated handler problem (Cairo: endRenderingHandler, Dakar: postRenderingHandler)

-- DanielRohde - 06 Feb 2006

Thanks Daniel fo keeping this Plugin compatible with Cairo and Dakar codebase

-- PeterThoeny - 08 Feb 2006

Daniel. When you fixed the mod_perl issue you must have created a new problem. This plugin as well as the HolidaylistPlugin floods the Apache error logs with more than 20 errors per plugin and only when mod_perl is enabled (for view only). And it happens when you click edit and when you save. No other of the many plugins I have installed does this. See Bugs:Item1596

-- KennethLavrsen - 08 Feb 2006

Hi Kenneth, I cannot reproduce your problem. I tested it with Apache/2.0.54, mod_perl/2.0.0, SuSe Linux 9.3. Please send me your mod_perl configuration and version numbers (e-mail: see TWiki:Main.DanielRohde).

-- DanielRohde - 08 Feb 2006

The Apache error_log flooding (apache 2.0.55/mod_perl 2.0.2 and selective mod_perl only for view) seems to originate from the statement.

use warnings;

It is probably a good idea to only run with this directive during development and comment it out when you release it.

-- KennethLavrsen - 09 Feb 2006

Thanx Kenneth, I removed use warnings; from the release.

-- DanielRohde - 09 Feb 2006

Hi all! Thanks for this Plugin, I like it

Is it planned to enable authentication for changing States? E.g I would love it, if only logged in people can change states, or even better, only people who are allowed to change the topic with the list in it, can change states.

-- SaschaVogt - 22 Mar 2006

Hi Sascha! I've commited a new revision to SVN that fixes the access right bug. Please checkout this new version, test it and give me feedback.

-- DanielRohde - 23 Mar 2006

Just if I get you right:

• svn co http://svn.twiki.org:8181/svn/twiki/branches/DEVELOP/twikiplugins/ChecklistPlugin/
• copy ChecklistPlugin.pm and ChecklistPlugin.txt into my TWiki-Installation
• restart Apache

2 Issues:

• my Sandbox web should be write-protected but a test checklist is changeable.
• on other webs I get: TWiki Installation Error
  Template "oopsaccesschange" not found.
  check the configuration setting for {TemplateDir}.

My TemplateDir should be set correctly...
Thx in advance

-- SaschaVogt - 24 Mar 2006

Hi Sascha! I found a compatiblity problem: Cairo uses oopsaccesschange and Dakar uses oopsaccessdenied. I'm looking for a solution that works with both releases. You can change oopsaccesschange to oopsaccessdenied in ChecklistPlugin.pm.

-- DanielRohde - 27 Mar 2006

Hi again! I've commited a new revision to SVN that should works with Cairo and Dakar. Dakar uses Error.pm and TWiki::OopsException instead of TWiki::Func::redirectCgiQuery with getOopsUrl.

-- DanielRohde - 27 Mar 2006

if I use Warning: Can't find topic ""."" to include a checklist, it get reset, seems the checklist info is stored in current page(not check source code yet)

-- XieXiaopu - 11 Apr 2006

Hi XieXiaopu, it's a feature: If you create a checklist template and include it with = Warning: Can't find topic ""."" = to a new topic the ChecklistPlugin creates a new <TOPIC>ChecklistItemState topic for this new topic. Please use the statetopic attribute to change this behavior .

-- DanielRohde - 11 Apr 2006

My team is using this plug-in on a day-to-day basis. We really like it for the most part - it's very configurable, and it makes something that SHOULD be easy, easy.

But we do have a couple of complaints. My team members complain that when they need to check off several items, they have to wait for the page to reload each time. Moreover, while the page tries to be smart and automatically scroll down to the item that you clicked on, nonetheless my users find it disorienting that, when the page reloads, it's almost always scrolled the page to someplace different than where they had been. The end result is that it slows down the process of checking off numerous items.

It occurs to me that perhaps the backend could be updated without any reloading at all. I know that this is possible in AJAX applications like, for example, the Google personalized homepage; but I imagine such technology would be difficult to add to TWiki if it's not already there. Perhaps you could consider this however: -When you click on an item, the page briefly opens a "pop-up" window; this window, of course, loads the ChecklistItemState page with the appropriate parameters to check the item in question. -The pop-up window is small and, if possible, doesn't become a top-level window in Windows. It also immediately closes itself. -The original page doesn't reload; but it uses Javascript to automatically change the image of the checklist item that was clicked.

This should keep the page correctly showing the correct state of the page as remembered by the backend; and should avoid the page having to reload.

Just some thoughts; perhaps all this is more trouble than it's worth, but I'm speaking for several day-to-day users of this module when I say it would be appreciated. Thanks again for making this very useful and mostly well-made plug-in!

-- ShayPierce - 13 Jul 2006

Hi Shay, thanx for your feature request. It's a nice idea. I will be on holiday for the next two weeks and I will implement and submit the next release after my holiday.

Just for info:

• You can disable the scrolling if you set anchors attribute to "no" (you can do that with a plugin setting * Set ANCHORS = no or with a tag attribute %CHECKLIST{anchors="no"}% )
• To check off several items you have several options:
  • Edit the matching ChecklistItemState topic directly
  • Split a single checklist into a group of checklists (see Example 4 on ChecklistPlugin topic) and enable 'reset' buttons (see Example 7 and 8 on ChecklistPlugin topic). A reset button can change a state for the complete checklist to the default or a given state. The %CHECKLIST% tag can be used more than one time in a checklist (or between %CHECKLISTSTART% and %CHECKLISTEND% ) to define 'reset' buttons or legends on different positions and with different 'target states'.

-- DanielRohde - 15 Jul 2006

Hi, I try to make a checklist with other images, but can't get it to work. It must be something simple, but I can't find it...

%CLI{stateicons="<img src=%<nop>PUBURL%/%<nop>TWIKIWEB%/UserDocGraphics/zonnig.jpg /> | <img src=%PUBURL%/TWiki/UserDocGraphics/bewolkt.jpg />|<img src=%PUBURL%/TWiki/UserDocGraphics/regen.jpg />|<img src=%PUBURL%/TWiki/UserDocGraphics/donder.jpg />" states="goed|voldoende|onvoldoende|slecht"}%

The image URLs work OK if I use them outside the CLI tag... Help appreciated!

-- JosMaccabiani - 28 Aug 2006

Hmm... it does work when I first create a variable for the images, e.g. %ZON%...

-- JosMaccabiani - 28 Aug 2006

WIBNIF: it would be really cool if you could include the state icon from one page in another page, with or without being able to change the state from this other page.

Use case: Several teams work using a balanced scorecard. They use ChecklistPlugin to keep scores on their team scorecard and a second check'list' of 1 image to summarise the score.

I'd like to build a summary page that shows that 1 image of all teams on one page.

-- JosMaccabiani - 28 Aug 2006

On my Dakar 4.0.4 hotfix 2 install, the default installation does cause notification of the *ChecklistItemState topics. Contrary to documentation!

Can this have something to do with "off" not being equal to off?

-- JosMaccabiani - 29 Aug 2006

Hi Jos, the notification problem is a bug. Please set notify to on to disable notification or fix it by putting a ! before $options{'notify'} in the line 756 of ChecklistPlugin.pm.

To build a summary topic you can use the current release:

1. edit your team based summary topics:
   1. give all team summary checklists a unique name (one per team): use the name attribute in all %CHECKLIST% and %CHECKLISTTART% and %CLI% tags.
   2. use the id attribute for your team summary score items (don't forget name attribute): see example 9 on the ChecklistPlugin topic
2. edit your global summary topic:
   1. put %CHECKLIST% tags to your summary topic (one per team summary); use the same attributes (name, stateicons, states ...) as on your team based summary topics and additionaly the statetopic tag (see docs)
   2. put %CLI% tags to your summary topic with name and id attributes matching the team summary score item id's
   3. put a warning to your summary topic that no one have to do changes on it by clicking on items because you cannot prevent changes (maybe with topic based access rights but not really recommended)

Have fun!

-- DanielRohde - 30 Aug 2006

Hi again, the publish release fixes bugs (notification ...) and I added a static attribute to disable state changes.

-- DanielRohde - 30 Aug 2006

Hi Daniel, thanks for the quick reply! I've installed the new version, however, notification still happens. I've tried the default setting, I've tried on , off , and "off" but still I get notified of the first CLI change per page (!)

-- JosMaccabiani - 30 Aug 2006

Hi, thanks for the explanation above, it works nicely. Just a thought - at first I used the same CLI tag on every team page because I included it from TWikiPreferences as a new parameter. So the strategy above did not work (but is easily fixed).

However, I think my approach should be able to work, since while name and id were identical, the combination of name, id and statetopic were unique.

The new static behaviour is very nice!

-- JosMaccabiani - 30 Aug 2006

Hello,

I've just started using the fine CL-plugin, but I face a strange behaviour: it's about setting States and StatesIcons in general preferences.

If I change them to 3, than I get correct appearance in a free hand list (ie with %CLI% tags)

But if I add a %CHECKLISTSART% %CL_END% way, the number of states fall down to 2.

more over, in the first case of a working 3 states list, in the TopicNameCheckListItemState one can only find and choose 2 states.

What am I missing ?

(BTW, is it possible to wideSet some attributes like CLIPOS or POS ?

Thank You !

-- RichardHitier - 12 Dec 2006

Hi Richard, thanx for reporting this bug. I've published a new bug fix release.

What do you mean with 'wideSet some attributes'? You can setup all attributes in the plugin settings section of the ChecklistPlugin topic (e.g:

   * Set CLIPOS = left

)

-- DanielRohde - 14 Dec 2006

Great ! It works well now, Thank you for the quick fix (Set CLIPOS = left works well, thank you)

-- RichardHitier - 15 Dec 2006

Hi there. I also agree that AJAX would be a better approach to changing the status. I've just installed this plugin on my CairoRelease site, and it looks good. One question about the item state page (see screenshot) which you can see is showing _default for the CONTEXT of each item. What is this context supposed to mean and why is it _default ?

I love the idea of being able to see the status for my checklist items in bulk, but how can I tell which item is which ? Thanks!

-- KeithHelfrich - 16 Dec 2006

Continuing to play with this some more, I see that for some reason it's not possible to escape the %CLI% variable with a $percent. What I'm trying to do is to make a simple checklist cheatsheet, that my users (and myself) can copy & paste from when they want to create a new checklist. The cheatsheet pops up on request in a small help window.

Here's the question about the escapes: I learned about the need for escapes in AccountLedgerApp. For me, in CairoRelease, everything works fine without the escapes. But someday I'll upgrade to Dakar and I was hoping to do things right the first time. Take a look at the difference between these two EditTablePlugin definitions and let me know why the second one doesn't work. (Of course, someday we'd like to EliminateNeedForEscapes)

Without the escapes:

With the escapes:

Looks like this is working fine without the escapes, even here at TWikiDotOrg. Maybe they're not necessary in this case ?

-- KeithHelfrich - 16 Dec 2006

The escape thing is still confusing to me, but as long as it's not necessary then no complaints! I'm sorry for the clutter on this page Going one step further, here is a handy preference variable that you could set in TWikiPreferences (or perhaps the plugin maintainers could set it for us in the plugin topic) :

   * Set CL = %EDITTABLE{changerows="add" editbutton="add TO-DO" format="|  label, 0, %CLI%  | text, 30 | text, 50 |"}%  %BR%
      | *Status* | *To Do* | *Comment* |

This will allow for any user to place only the %CHECKLIST% variable into their topic and receive a ready-to-use table like the one above.

Word of caution: this variable works on DakarRelease but not on CairoRelease

-- KeithHelfrich - 18 Dec 2006

Hi Keith, please do not use a %CHECKLIST% for a variable name. And if you use select,1,%<nop>CLI% instead of label, 0, %CLI% it should work with Cairo too. The <nop> quotation works within select but not within label (maybe a Cairo EditTablePlugin bug?).

The _default context in the item state topic means that the checklist has no name. You can give a checklist a name ( name attribute). This allows you to put more than one checklist to a topic or you can use it for other strange things (checklist splitting for easy item inclusion, checklist state merging, checklist state archiving ...).

-- DanielRohde - 08 Jan 2007

Hi, I've published a new BETA release to SVN that uses AJAX for state changes. Please feel free to test it and give me a little bit feedback here.

-- DanielRohde - 11 Jan 2007

Daniel. Your checkins continue to be on the wrong SVN branch.

All plugin development is on the MAIN branch and has been for quite some time.

-- KennethLavrsen - 15 Jan 2007

Hi Daniel, I've changed the above to use %CL% instead of %CHECKLIST%. A couple of questions :

• Is the ...ChecklistItemState topic meant to be viewed by regular users ? Or is it only used by the plugin to keep track of the various item states ? Is a way to make the contents of the page more intelligible (or useful) to users ?
• I'm eager to use the new AJAX version of your plugin. Is it expected to run as-is on CairoRelease ?

Thanks for the above help re: select vs. label in the EditTablePlugin.

-- KeithHelfrich - 15 Jan 2007

Hi Kenneth, sorry, all my changes will be done in the MAIN branch now. svn co "http://svn.twiki.org/svn/twiki/trunk/ChecklistPlugin" should work now and contains a new BETA release with a minor bug fix and a performance improvement.

Hi Keith, the ChecklistItemState topic can be used by regular users and keeps track of all item state changes. What do you mean with intelligible (or usefull) to users? Users should change states by clicking icons but advanced users can do that quickly by editing the item state topic.

I've tested this plugin only with the CairoRelease yet but with DakarRelease it should also work (I hope).

-- DanielRohde - 16 Jan 2007

The reason I think the ChecklistItemState topic is unintelligible is mostly because it doesn't give me any sort of clue about what each checklist item is (only the ID).

Below is an example table from one of my own ChecklistItemState topics. While I'd love to edit the table directly, I'd first have to go to the checklist & figure out what in the heck the correct ID is. And especially with AJAX, in that case I'd might as well just click the %CLI% and forget about editing the table ...

I dunno if there's a way to include a short description, or something more than the ID, but if so then I think that would be helpful (especially for mass updates).

I'm looking forward to trying out the new AJAX on my CairoRelease Thanks!

-- KeithHelfrich - 16 Jan 2007

Hi Daniel, just a few minutes later. I've upgraded to the AJAX version of the ChecklistPlugin and here's what I have to report :

• The upgraded plugin .ZIP clobbered over my customized settings of %STATES% and %STATEICONS% in ../twiki/data/TWiki/ChecklistPlugin.txt
  • the way to get those customizations back was to restore ChecklistPlugin.txt from backup and then merge them in
  • if I had anticipated the problem, I would have grabbed those customizations before clobbering them
• The new AJAX functionality is working correctly on CairoRelease.
  • Things are now much prettier, but I don't find them to be any faster with AJAX

Some recommendations / brainstorms for things that could be done from here....

• Customizable TOOLTIP message to display over checklist icons, so that newbies know they can click on them
• Somehow work on the performance to make switch between CL items faster / quasi-instantaneous
• Clicking sequentially through all of the different %STATES% is tedious when there are lots of them
  • perhaps turn the existing javascript call into a popup window, similar to the various popup calendars that are out there ?

All in all, a nice enhancement. While it isn't noticeably faster, it's certainly a LOT NICER now that the page doesn't need to reload !

-- KeithHelfrich - 17 Jan 2007

Hi Keith, I've checked in a new revision to SVN. I've added some new features and improvements:

• descr attribute (take a look at the Attributes section)
• tooltip attribute: take a look at the Plugin Settings and Attributes sections
• the row order of the item state table on the ChecklistItemState topic matches the item order of the checklist now
• better installation instructions

There are some reasons why the AJAX feature is not really faster than the old behavior. A checklist can be changed by different users (concurrency). Therefore I have to wait for a response from the server before I can change a checklist item. Another reason is that a user can leave the topic before a change was done. If I change a checklist item immediately (without a response from the server) a user can think a change was done and leave the page.

A popup window for a quick state change is not easy to implement. I'm not really a JavaScript fan and a feature like this must work with different browsers (I hate the IE). I have no time to implement this yet.

-- DanielRohde - 18 Jan 2007

Daniel, you're fast !! The new features sound great. I'll have to wait for the .ZIP to be attached here to the ChecklistPlugin page, tho, because SVN is still one of those mysteries to me & I have no idea how to work with it.

Your javascript gripe is understandable. Perhaps a dropdown instead ? (but then that's not very pretty). I'm just trying to think of ways avoid clicking & waiting through a long list of %STATES% sequentially (especially when you don't know which one comes next & you're just curious). The easiest solution, I suppose, is to keep it simple on the number of %STATES% that are available to begin with.

-- KeithHelfrich - 19 Jan 2007

Hi Keith, you can checkout a new revision with following command (svn binary needed):

svn co "http://svn.twiki.org/svn/twiki/trunk/ChecklistPlugin"

or just click on following link:

http://svn.twiki.org/svn/twiki/trunk/ChecklistPlugin

-- DanielRohde - 19 Jan 2007

Hi Daniel, with the new ChecklistPlugin.pm found in SVN do you find that the %TOOLTIP% is working ? I find that the ALT message now displays the URL of the %STATE% icon (whereas in the past it would display the ALT message defined for the icon in TWikiDocGraphics. In neither case is there a TOOLTIP. Is this just me ?

-- KeithHelfrich - 20 Jan 2007

As an aside, I was doing my homework and reading thru what's new in the Edinburgh release. See the 2nd bullet point re: "it is recommended to set the plugin settings in TWikiPreferences, and not to customize the settings in the plugin topic". (If I could ever get off of CairoRelease, it seems this nice new feature was developed to prevent the clobbering of plugin VARS that happened earlier ...).

Also later in the same topic I see "The view script supports a section URL parameter to view just a named section within a topic. Useful for simple AJAX type applications." I'm not sure if this would help with the performance questions we've been talking about.

-- KeithHelfrich - 20 Jan 2007

Another feature / function that I just thought of: Wouldn't it be nice to have %STATES_TEMPLATES% ? For example, if I commonly use the ChecklistPlugin for two very different applications then why should I be forced to manually define the %STATES% every time that I use the "other" application which wasn't lucky enough to have it's states defined by default in the plugin settings ?

This would simply the declaration of a new checklist for the 2nd, 3rd, 4th (and every additional) commonly used application to something like %CHECKLISTSTART{template="househunting"% vs. %CHECKLISTSTART{template="todo_items"%

Again, a very useful & appreciated plugin. Hence the ideas

-- KeithHelfrich - 21 Jan 2007

Hi Keith, the new !ChecklistPlugin.pm works only with the new itemstatechange.js (pub/TWiki/...).

The new section URL parameter don't reduce the rendering effort. Therefore it cannot speed up the AJAX feature.

Thanx for your feature request.

-- DanielRohde - 22 Jan 2007

Thanks Daniel. Since I didn't have the svn binary available I had grabbed the changes from the useful link you gave and forgot to pull down the itemstatechange.js. The customizable tooltip is very attractive.

My next test finds that the descr attribute isn't working. Perhaps I'm missing another file from SVN ? The ItemState topic does have a description column in the table. However, all values are blank despite %CLI{descr="quick test"}% and %CLI{"my description"}% in the checklist.

-- KeithHelfrich - 22 Jan 2007

Hi Keith, I cannot reproduce your descr problem. I need some information: TWiki release, mod_perl?, cache AddOn ?

PS: There is a new revision with a small performance improvement (I added skin=print to all AJAX request URLs).

-- DanielRohde - 22 Jan 2007

Hi Daniel,

• TWiki version = 04 Sep 2004 $Rev: 1742
• Perl version = 5.8.6
• Neither ModPerl nor any cache add ons

I'm also seeing some other unwanted behaviour. For example, if I edit a table that has a long list of %CLI% variables in column #1 and add a new row somewhere in the middle of that table, I find that the %STATE% settings for all of the checklist items that existed previously are now offset and the states did not follow the items to their new row.

In another example, I've got a pair of %CLI% variables that no matter how many times I click, they will not advance to any %NEXTSTATE% beyond the 2nd one. And for those two %CLI% variables, when I refresh the page, their %STATE% values are reset to initial.

Maybe both of those problems stem from an older perl version ?

On the features front, what would be great is an automatic assumption of the $descr attribute based on the next column over in the table. For example in a table of the design

Status	To Do	Comment
%CLI%	have a nice day

it would be ideal if the the $descr attribute were automatically assumed for each %CLI% to be whatever the value is that's found in column #2 for that row. This would allow new %CLI%'s to be added automatically vis a vi QuickCheckListApp and also allow statuses to be maintained in bulk vis a vi ChecklistItemState

-- KeithHelfrich - 25 Jan 2007

Daniel - I'd like to make a case to reconsider your thinking about slow performance versus juggling multiple user input. For myself, the lag between clicking and having the state change almost makes it unusable. I think many users would end up clicking it repeatedly - causing further delays and confusion. The case where another user is clicking the same item at the same moment seems like a remote possibility that's not worth the performance tradeoff. Regarding the case of leaving the page, is there someway to give some additional visual feedback that something's happening? A little animated gif off to the side or something?

Thanks for your work on this. It could develop into an essential tool!

-- LynnwoodBrown - 25 Jan 2007

I agree with Lynnwood, both on the essential tool and 'the lag is a drag'. The "click and wait" is just too much & instead one really needs to be able to choose the state once from a list (be it calendar pop-up style list or traditional dropdown style list) and move on ..

In fact, I'm thinking that perhaps my two bunky CLI's that won't behave now might have started acting up when I grew impatient with the "click and wait" and tried to skip instead to the ChecklistItemState topic .. that didn't work, back to the CLI, click click click ... argh, now the whole thing is messed up. Patience is a limited virtue

-- KeithHelfrich - 25 Jan 2007

Hi, I've checked in a new revision that manipulates the mouse cursor and the tooltip text if a state change is in progress.

It's a known issue that states are lost If you insert a new checklist item into an existing checklist with modified states (Example 9 at the ChecklistPlugin topic).

Sorry, I cannot reproduce the descr problem (perl v5.8.7, Cairo and Edinburgh with and without mod_perl, Browsers: Firefox 2.0, IE7, Opera 9).

To the problem with multiple clicks and state lost: please send me the URL parameters of the checklist items (especially the clp... parameters).

I cannot get a field from a table to fill the description field because the CLI can also be placed in bullet lists or in paragraphs or in ... . The real problem is how the CLI items are processed by a TWiki plugin. Maybe I have to restructure the code (really very expensive). I'm thinking about that. Maybe I will strip some text from the line (text before and after a CLI item).

A drop down selector could be an optional add on as a replacement for the tooltip text but I need example code that works with all browsers and is easy enough to adapt it.

-- DanielRohde - 26 Jan 2007

... ok, a description is stripped from the text before and after a checklist item. Maybe a character limitation is useful (and comes with next checkin).

-- DanielRohde - 26 Jan 2007

I've added the template feature. You can setup all attributes bounded to a template name.

-- DanielRohde - 29 Jan 2007

Ok, the state selection popup works (set statesel to on) but I have trouble with the mouse cursor (wait cursor with statesel does'nt work yet).

-- DanielRohde - 29 Jan 2007

Hi Daniel, I've tested the new version that you have in SVN and here's what I have to report:

• the templates seems to be working correctly, this is a nice new feature
• the selection pop-up also appears to work correctly on both firefox and IE, also very pretty

Some nice-to-haves on the pop-up select :

• if it wouldn't pop-up until you click on the item that you want to change (instead of on mouseover)
• if the pop-up would automatically close after you have chosen from the list
• if the STATESEL = on setting could be made globally as a Plugin setting (this does work if used in a template but cannot be set to "always on")

But the larger problem I'm experiencing is the following: while my checklists appear to be working correctly, states change when I click on them, every time I refresh the page the states are reset to the way they were when I started (often, this is the initial state.. if the checklist is new since upgrading to the versions in SVN). To confirm what is happening, I've started with a brand new topic in my sandbox web. The problem is that the ChecklistItemState topic is not being updated.

Something must have changed in the recent versions, because in the past of course the plugin was working correctly. Can you picture a reason why the ChecklistItemState would not be updated ? This, I think, also explains my two item states that were misbehaving previously.

-- KeithHelfrich - 30 Jan 2007

Well, I reverted to the previous versions of ChecklistPlugin.pm and itemstatechange.js that I was using on Jan 22, the ChecklistItemState topic is updated correctly. Then I switched to the versions I was using on Jan 30, and the ChecklistItemState topic is updated correctly. Then I switched back to this, the most recent version and the ChecklistItemState topic is not updated correctly. Also, if I start a brand new topic & drop in a %CLI%, then the ChecklistItemState topic that gets created on the first state change has a problem in the %CALC% command. See the screenshot (bad calc command on 1st creation of the ChecklistItemState topic)

-- KeithHelfrich - 30 Jan 2007

Hi Keith, thank you for the bug reports and feature requests. I've published a new revision to SVN that fixes this bugs and added new features. I've tested it with Cairo and Edinburgh (with and without mod_perl) and different browsers (IE 7, Opera 9 and Firefox 2).

-- DanielRohde - 30 Jan 2007

Hi Daniel, on the contrary. Thank you! for the prompt response. It is quite a pleasure to participate in testing & feedback when the response times are fast and when it's obvious that we are making noticeable improvements!

Here is what I find after testing the most recent version in SVN :

• the plugin works as advertised!
• the pop-up menus, tool tips, and state selection process are now very much friendlier to use.
• for me, the descr description column still is not populated on the ChecklistItemState page. But I know you've been unable to reproduce this yourself.

The next big hurdle I can see is getting around the problem that occurs when a new checklist item is "inserted" into the middle of a page that already has checklist items on it. From a usability standpoint, this is a real problem because the whole point of a wiki system is to let people flexibly change what they want and insert content where they see fit. The way the plugin works at the moment, folks are pretty much "forced" to add new checklist items only to the bottom of the topic. Doing anything else at all will offset the state for every other item on the page and effectively "mess-up" everything that was previously accomplished with the checklist, resulting in chaos. :-/

So if a large topic would naturally have three or four different sections in it, separated by headings. Then we need to be able add and remove checklist items anywhere in the topic, while preserving the state of those items that were there previously.

In a similar vein, what happens if :

• revision A: add an item and change the state
• revision B: delete that item, don't want to keep track of it afterall
• revision C: add a new item in it's place (is the new item's state new?)

So, for real-time use, there has got to be some kind of "hard link" between a given item and it's state in the ChecklistItemState topic (more than just vertical position on the page).

The code below in one of my topics has really got the plugin confused at the moment. My end goal is for something like this to work correctly :

---++ List 1

%EDITTABLE{changerows="on" editbutton="add to list 1" quietsave="off" format="| label, 0, %CLI% | text, 30 | text, 50 | text, 50 |"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |
| %CLI% | list 1 item 1 |  |  |


---++ List 2


%EDITTABLE{changerows="on" editbutton="add to list 2" quietsave="off" format="| label, 0, %CLI% | text, 30 | text, 50 | text, 50 |"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |
| %CLI% | list 2 item 1 |  |  |


---++ List 3

%EDITTABLE{changerows="on" editbutton="add to list 3" quietsave="off" format="| label, 0, %CLI% | text, 30 | text, 50 | text, 50 |"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |
| %CLI% | list 3 item 1 |   |  |

But all of that said: again, congratulations on some serious improvements recently. The pop-up menus, AJAX, tooltips, and other features are super. If we can get over the problem mentioned above, then it will be hard for me to continue making suggestions

-- KeithHelfrich - 30 Jan 2007

So I guess it's time to publish it here on TWiki.org, isn't it?

-- FranzJosefSilli - 30 Jan 2007

Hi Keith, thank you for your feedback. You can fix your 'insert' problem with some small changes:

1. install the new revision from SVN
2. add %CHECKLISTSTART%/%CHECKLISTEND% before/after every table with a unique name attribute
3. replace label, 0, %CLI% with select, 0, %<nop>CLI%

Here is the complete example:

---++ List 1

%CHECKLISTSTART{name="list1"}%
%EDITTABLE{changerows="on" editbutton="add to list 1" quietsave="off" format="|select, 0, %<nop>CLI% |text, 30 |text, 50 |text, 50|"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |
%CHECKLISTEND%

---++ List 2

%CHECKLISTSTART{name="list2"}%
%EDITTABLE{changerows="on" editbutton="add to list 2" quietsave="off" format="| select, 0, %<nop>CLI% | text, 30 | text, 50 | text, 50 |"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |
%CHECKLISTEND%

---++ List 3
%CHECKLISTSTART{name="list3"}%
%EDITTABLE{changerows="on" editbutton="add to list 3" quietsave="off" format="| select, 0, %<nop>CLI% | text, 30 | text, 50 | text, 50 |"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |
%CHECKLISTEND%

-- DanielRohde - 31 Jan 2007

... another way to "hard link" a %CLI% item with it's state: use the id attribute.

-- DanielRohde - 31 Jan 2007

... maybe: %CLI{id=\"%SERVERTIME{$day$mon$year$hour:$min:$sec}%\"}%

-- DanielRohde - 31 Jan 2007

Hi, I've published the new version (v1.021 - see ChecklistPlugin topic).

-- DanielRohde - 31 Jan 2007

Hi Daniel, the version available in SVN seems to have gone backwards in time. The ChecklistPlugin.txt states the following under plugin info, and the new features have all gone missing. So I'm still using the most recent version that I had previously downloaded from SVN, presumably the same that is now attached to the ChecklistPlugin topic.

v1.016 (18 Apr 2006)

TWiki:Main.DanielRohde: fixed access right bug reported by TWiki:Main.SaschaVogt

-- KeithHelfrich - 01 Feb 2007

I'm searching for the holy grail for my QuickCheckListApp

Ideally we could use your %CLI{id=\"%SERVERTIME{$day$mon$year$hour:$min:$sec}%\"}% statement in the edit table cell, also. This would "hard link" each checklist item to it's state, protecting against the rare person who inserts a new row manually into the middle of the table and skips the edit table button.

But doing so precludes you from adding 2 or more rows at the same time with the "add row" feature. That's because each additional row receives a %CLI with the same ID (the server time at the time of adding the additional row).

I've also tried the following, and that doesn't work, either, because each table edit re-randomizes all of the IDs, thus setting all of the states back to new.

select, 1, %CLI{id=\"%CALC{$RAND(1000000)\"}%}%

A follow-up question was asked in EditTablePluginDev.

-- KeithHelfrich - 02 Feb 2007

argh.

I wanted to go and add the %CHECKLISTSTART% and %CHECKLISTEND% tags to an existing topic with multiple lists in it, so that I could give each list a unique name. That doesn't work very well. Since the name wasn't there from the start, all of the existing states still have a context = _default

So I deleted the ChecklistItemState topic with plans to create a new one by re-entering all of the states (this time with context = name)

The good news first: now all of a sudden the descr column is filled in for me in the ChecklistItemState topic It's not very useful information because it's just a bunch of EditTablePlugin stuff, but at least it's there & visible. Still hoping to someday get the value of the next right-most cell in the table.

But two new problems. When all of my states were reset to initial because of the missing ChecklistItemState topic, I went about the process of putting them back the way they were.

This particular topic has a very large number of items in it, I count 60 checklist items in 5 separate lists. When I went to change the states by selecting from the javascript pop-up, it max'd out the CPU on my PC (firefox = 100%) for some time, and only then will the state icon change. More specifically, the sequence of events goes like this :

1. select state from javascript pop-up
2. normal delay, CPU is idle (this I believe is the AJAX call in progress)
3. AJAX returns, then firefox spikes the CPU to 100% for 3 - 5 seconds
4. CPU returns to idle, and the state icon has changed.

But worse, the newly created ChecklistItemState topic was found to have received a bunk entry. I refreshed the checklist page, and sure enough, all of the states were back to initial values. See bunk entry below (the ID should not be 1, since it's not the first CLI on the page and the state should not be 'new' since I chose to set the state to 'postponed').

When I change the state of other CLI's on the page, the same is still true: CPU problem repeats, ChecklistItemState topic only has one bunk entry. :-|

-- KeithHelfrich - 02 Feb 2007

Hi Keith, try out the GuidPlugin to get a unique id instead of %SERVERTIME% or %CALC%.

I use JavaScript with many regular expressions to modify the page. I know it is not a good idea but I have trouble to use XML responses yet (Firefox means that the response is not well-formed and IE7 doesn't find anything if I use XPath searches). I've published a new revision (>=12716) to SVN that reduces the 'search-and-replace' operations but it cannot avoid CPU peaks yet.

If you put the %CHECKLISTSTART{name="..."}%/%CHECKLISTEND% to an existing checklist the old states are lost but you do not need to clean the ChecklistItemState topic. I cannot reproduce your problem with the 'bunk entry'. Do you really use the current ChecklistPlugin version and Cairo without mod_perl?

-- DanielRohde - 02 Feb 2007

Hi Daniel,

I have just done the following :

1. downloaded and applied the current zip file from ChecklistPlugin topic
2. created a new topic in my Sandbox web
3. pasted the three lists from your #ListExample on Jan 31
4. used the EditTablePlugin to add 2 items to each list
   • called List 1 Item 1 , List 1 Item 2, etc.
5. changed the state of List 1 Item 2 from 'new' to 'postponed'
6. checked the ChecklistItemState topic to see what I would find :

Note that the CPU problem definitely does not occur with such a small list. It is only when changing the state of an item that is found in a topic with very many lists and items.

-- KeithHelfrich - 02 Feb 2007

Hi Keith, I've done the same steps and - sorry - it works (maybe I need your ChecklistPlugin settings). Please take a look at your Apache's error.log and TWiki's warning.txt (any errors?). I've tested it with 04 Sep 2004 $Rev: 1742 $ (without mod_perl2, Apache, perl v5.8.7 - Ubuntu 6.06.1 LTS).

-- DanielRohde - 05 Feb 2007

Hi Keith, I've published a new revision to SVN with new features:

• allow TextFormattingRules and HTML in tooltip
• allow # _ID_ tags between %CHECKLISTSTART%/%CHECKLISTEND%

This allows you following (tested with Ciaro and Dakar):

---++ List 1
[[%TOPIC%ChecklistItemState]]
%EDITTABLE{changerows="on" editbutton="add to list 1" quietsave="off" format="|label, 0, #%SERVERTIME{$year$month$day$hour$min$sec}% |text, 30 |text, 50 |text, 50|"}%%CHECKLISTSTART{name="list1"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |

%CHECKLISTEND%

---++ List 2
%EDITTABLE{changerows="on" editbutton="add to list 2" quietsave="off" format="|label, 0, #%SERVERTIME{$year$month$day$hour$min$sec}% |text, 30 |text, 50 |text, 50|"}%%CHECKLISTSTART{name="list2"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |

%CHECKLISTEND%

---++ List 3
%EDITTABLE{changerows="on" editbutton="add to list 3" quietsave="off" format="|label, 0, #%SERVERTIME{$year$month$day$hour$min$sec}% |text, 30 |text, 50 |text, 50|"}%%CHECKLISTSTART{name="list3"}%
| *STATUS<br>(click to change)* | *Item* | *Comment* | *Customizations* |

%CHECKLISTEND%

%EDITTABLE and %CHECKLISTSTART% have to stay in the same line. This example allows you to add, insert or remove items without state lost.

-- DanielRohde - 07 Feb 2007

... ok - I've fixed a major %CLI% substition bug (Rev >=12796; since description is stripped from text before and behind a %CLI% tag).

-- DanielRohde - 08 Feb 2007

Hi Daniel. Many thanks for this plugin. I have used it within Issues lists, where the issue header (2nd level ---++) has a togglable icon appended to it, indicating whether it is open or closed.

My issue is that I am using it in conjunction with a table of contents (from which I can quickly scan the state of all issues on the page). The icons are displayed fine in the table of contents. However, when I go to a header and change its icon state, the icon in the table of contents changes, but the one which I actually clicked on to change, doesn't. It requires a complete page refresh to get it to display correctly.

Do you have a work-around for that?

-- HelenJohnstone - 08 Feb 2007

Hi Helen, I have only one work-around for that: disable AJAX, e.g: %CHECKLIST{useajax="off"}%

The problem: I use ID attributes to identify and modify checklist icons with JavaScript. The %TOC% tag duplicates this ID attributes but (X)HTML does not allow duplicate ID's in a (X)HTML document and JavaScript knows only a document.getElementById not a document.getElement s ById.

I'm thinking about that but I don't know how to fix it yet.

-- DanielRohde - 09 Feb 2007

Ok - Helen, please checkout the latest release (SVN Rev >=12816). You need the new ChecklistPlugin.pm and the new itemstatechange.js.

The solution: I use the name attribute to change the icons. But it works only with Dakar and Edinburgh. The fix does not work with Cairo because a link ( a tag) has no name attribute and Cairo does not remove links from a %TOC%.

-- DanielRohde - 09 Feb 2007

Hi Daniel, I've downloaded the latest release from SVN (SVN Rev >=12816). And I tested with your most recent list example and it is working correctly. To be doubly safe, I also downloaded the most current version of the EditTablePlugin.

So now, I'm happy to report, that everything is working as advertised ( even for me )!

• each new item receives a unique ID, even if you add more than 1 item at a time using the EditTablePlugin's add new row
• items can be moved around manually within the same list without state loss
• new items can be inserted manually anywhere in the list, with manual use of the #ID in the CLI cell
• the auto-filled descr column in the ChecklistItemState topic is also now very convenient and does the trick by allowing mass edit of item states.

I'm happy enough with this that I think I'll go now to update the QuickCheckListApp topic. I'd also think that you can publish the SVN version here on twiki.org. It looks good.

What do you think about building in a new plugin variable that would make adding these types of EditTablePlugin based checklists super easy to use ? For example, %CHECKLISTTABLE{name="list1" col1="item" col2="comment" col3="customizations"}% would be interpreted as the whole shebang for list 1 from your list example and it would produce the TableWidgkit straight away & easy. Default columns for %CHECKLISTTABLE% could even make using at easy as adding only the variable itself.

-- KeithHelfrich - 10 Feb 2007

Just tried your mod Daniel. Works a treat. Many thanks for both the fix and the very quick turn-around

-- HelenJohnstone - 13 Feb 2007

Hi again Daniel. I've come across another odd one with this. I've set up a comment template that allows someone to create a new issue, and it adds a checklist item alongside it. The comment is:

%TMPL:DEF{PROMPT:NewIssueStatus}%
|  *New Issue* | <textarea cols="80" rows="1" name="NewIssueName"></textarea>  |
| <input type="submit" value="Add new issue" /> ||
%TMPL:END%



%TMPL:DEF{OUTPUT:NewIssueStatus}%
%POS:ABOVE%

---++ %URLPARAM{"NewIssueName"}% %CLI%

%TMPL:END%

The new item is added as a header - level 2 (H2). It has a CLI at the end of the header. The page has an embedded

%CHECKLISTSTART{states="open|closed" stateicons=":)|:("}% %CHECKLISTEND%

line at the top of the page to define the 2 states: open and closed.

When I add a new item via the Comment box, the new header is created below the comment box. Rather than defaulting to the status of Open, the checklist status of the new comment takes the status of the comment directly below the new comment, and changes that status (of the one underneath) to 'open'.

I've tried stating the default 'open' state for new checklist items, but that didn't change the behaviour. I've also tried having 3 states, but it still behaves as above.

Any ideas?

-- HelenJohnstone - 15 Feb 2007

Hi Helen, please change your template: replace the %CLI% tag with %CLI{id="%SERVERTIME{$year$month$day$hour$min$sec}%"}%

You do not need to define the states with %CHECKLISTSTART%/%CHECKLISTEND%. Simple put a %CHECKLIST{states="open|closed" stateicons=":)|:("}% to your OUTPUT definition.

-- DanielRohde - 16 Feb 2007

From either Daniel or Helen, could we get an "official" version of the working template ?

-- KeithHelfrich - 16 Feb 2007

Bug report : when using a table like the one in #ListExampleFeb7, the ChecklistPlugin gets confused and does not react well to WikiWord links that use an anchor (for example, the wiki word ChecklistPluginDev would break). Presumably this happens because the # sign in the anchor is interpreted by the plugin as a new %CLI% with ID equal to #AnchorName

-- KeithHelfrich - 17 Feb 2007

... fixed (SVN Rev >=12917).

-- DanielRohde - 19 Feb 2007

... and I've fixed a tooltip positioning bug (tooltips of checklist items in tables are placed correctly now). There are two new attributes ( tooltipfixleft, tooltipfixtop) to fix the tooltip position because if you use the PatternSkin the "normal" position calculation does not work correctly.

-- DanielRohde - 19 Feb 2007

Many thanks Daniel for a great feature.

-- HelenJohnstone - 21 Feb 2007

I'd like to show who last modified the state or the title of the CheckList item. That way I'd know who to talk to if something was marked done, BUT wasn't !

-- JasonMurdoch - 05 Jul 2007

I don't know what you mean. Take a look at the _YourCheckListTopic_ChecklistItemState topic to see a change history ...

-- DanielRohde - 05 Jul 2007

Hi Daniel,

The %EDITTABLE% doesn't work when schrunched between %CHECKLISTSTART% and %CHECKLISTEND%

When I try to insert row or edit existing ones, it's bunky. Do you have any idea why ?

%CHECKLISTSTART%

%EDITTABLE{changerows="on" editbutton="Edit Checklist" quietsave="off" format="|label, 0, #%SERVERTIME{$year$month$day$hour$min$sec}% | text, 30 | text, 50 |"}%
| *STATUS* | *Requirement* | *Comment* |
| #2007Aug02214705 | trust | |
| #2007Aug02214707 | hope | |
| #2007Aug02214709 | fear | |


%CHECKLISTEND% 

-- KeithHelfrich - 03 Aug 2007

Hi Keith, please put the %EDITTABLE% tag before the %CHECKLISTSTART% tag and in the same line (see ChecklistPlugin Example 6)

-- DanielRohde - 03 Aug 2007

Thanks, that did the trick. I think we've covered this in the past, as well. Sorry about that. Can I ask you for a favor ? Is there any way at all to enhance this plugin and add a %CHECKLISTTABLE% variable.

I'm desperately seeking a variable that would, with a single stroke, insert a ready-to-use checklist table into the topic. NerdoMeter = 0. Ideally, a CommentPlugin template would also be involved and allow quick insert into the table (instead of 3 clicks for the EditTablePlugin to insert a new row).

All of my attempts to build the elusive QuickCheckListApp have failed, and I think it might work better if you were to build it directly into the ChecklistPlugin. What do you think ?

-- KeithHelfrich - 03 Aug 2007

See also related: Bugs:Item4423

-- KeithHelfrich - 03 Aug 2007

Okay Keith, I'm thinking about that. But we need to discuss some requirements. It should be easy to use but customizable too (table format, table header/caption, comment type, formular before/behind table ...????).

A big problem is the dependency to a CommentPlugin template. A good way is perhaps a new plugin called ChecklistTablePlugin to marry ChecklistPlugin and CommentPlugin with some new parameters for customization. But I don't know how can I create dynamic CommentPlugin templates. Maybe I do not use CommentPlugin templates and create own HTML forms and do the same like CommentPlugin and/or EditTablePlugin ... but this is very expensive.

Any other ideas are welcome.

-- DanielRohde - 03 Aug 2007

Let's see. My simple requirement would be a 3 column table with the %CLI in the first column, a generic term "Item" in the second column, and a comment in the third. The %CLI should always be unique, to prevent sequence problems in case a new row is added manually in the middle of the table.

The above can be achieved with :

%EDITTABLE{changerows="on" editbutton="Edit Checklist" quietsave="off" format="|label, 0, #%SERVERTIME{$year$month$day$hour$min$sec}% | text, 30 | text, 50 |"}%
| *STATUS* | *Item* | *Comment* |

From there, nice-to-have's would be the ability to customize your own table column names. And perhaps to have multiple CHECKLISTTABLE's per topic, with a name attribute. For example, with :

%CHECKLISTTABLE{name="first table" column1="To Do" column2="assigned to" column3="comment"}%

Any other attributes that you could add in would only make things better.

As for inserting new records, I actually wish that the EditTablePlugin would be modified to reduce the number of clicks needed for inserting a new row. That would make the whole question of the CommentPlugin template go away.

But that development pending, we could either :

1. make the addition of a UserCommentsTemplate a necessary step during installation of the plugin (else, %CHECKLISTTABLE% would not work correctly
2. create own HTML forms and do the same like CommentPlugin and/or EditTablePlugin ... but this is very expensive.
3. steal some code from the CommentPlugin and include it here
4. give up on the auto-inserting of new rows for now ..

Of all the above, fixing the EditTablePlugin to reduce the number of clicks needed for inserting a new row seems most appropriate to me. But as a non-programmer I concede :-|

Again, the goal is to make it easy to drop a self-serving & useful table into the topic with just a single %CHECKLISTTABLE% .. no customization necessary ... (don't make me think)

-- KeithHelfrich - 03 Aug 2007

Hi Keith, there is a first release of ChecklistTablePlugin ... I need feedback ...

-- DanielRohde - 28 Aug 2007

There seems to be some odd behavior in the access control processing. When I specify Set DENYWEBCHANGE = user in the WebPreferences topic of a web, checklists have properly restricted access. If I set the same variable in Main.TWikiPreferences, the checklists can be edited by anyone, but the other topics in the web have the correct access control.

-- PrasannaVelagapudi - 20 Mar 2008

I have been trying to configure a nice todo list for a while and finally came up with the following setup that will record the listing date as well as the date it is finished without having to specifically set these dates.

If anyone has a better way to do this, I would love to see it, but so far this is the best I have been able to put together from examples and my own experimentation.

Here it is:

*Example !ToDo List*

--- %CHECKLISTSTART{states="todo|started|done-07 Sep 2008" stateicons=""}% %TABLE{sort="off" initsort="1" initdirection="up" }% | *State* | *Description* | *Date Listed* | %CHECKLISTEND%

-- HunterMoseley - 07 Sep 2008

Let me try commenting this again:

<h1 align="center"> *Example !ToDo List* <br /></h1> <br /><br /> 

---



%CHECKLISTSTART{states="todo|started|done-"07 Feb 2026"" stateicons=""}%

%TABLE{sort="off" initsort="1" initdirection="up" }%

| *State* | *Description* | *Date Listed* |



%CHECKLISTEND%

-- HunterMoseley - 07 Sep 2008

I hope the 3rd try is the charm:

<h1 align="center"> *Example !ToDo List* <br /></h1> <br /><br />

--- %EDITTABLE{ format="| label,0,#2008Sep07094801 | text, 100, | label, 0, 07 Sep 2008 | date, 20, 0, |" header="|*State*|*Description*|*Date Listed*|" changerows="on" }%!%CHECKLISTSTART{states="todo|started|done-07 Sep 2008" stateicons=""}% %TABLE{sort="off" initsort="1" initdirection="up" }% | *State* | *Description* | *Date Listed* | %CHECKLISTEND%

-- HunterMoseley - 07 Sep 2008

Let's see if the 4th try will get this:

%EDITTABLE{ format="| label,0,#!2008Sep07095018 | text, 100, | label, 0, !07 Sep 2008 | date, 20, 0, |" header="|*State*|*Description*|*Date Listed*|" changerows="on" }%!%CHECKLISTSTART{states="todo|started|done-!07 Sep 2008" stateicons=""}% %TABLE{sort="off" initsort="1" initdirection="up" }% | *State* | *Description* | *Date Listed* | %CHECKLISTEND%

-- HunterMoseley - 07 Sep 2008

Hi Hunter, please try the ChecklistTablePlugin. It's an editor like EditTablePlugin and EditRowPlugin and supports a item column type, e.g:

%CHECKLIST{states="todo|started|done" stateicons=":-(|:-I|:-)"}%
%CHECKLISTTABLE{format="|item,0|text,100|label,0,%<nop>SERVERTIME{$day $month $year}%|date,20|" header="|*State*|*Description*|*Date Listed*|*Date*|" changerows="on"}%

-- DanielRohde - 08 Sep 2008

Seeing strange output since moving to TWiki-5.0.2, Tue, 03 May 2011, build 21156, Plugin API version 1.3 and plugin v. v1.028. Attached a screen shot. The code generating the output:

%CHECKLISTSTART{ name="all" states="todo|done|NA" stateicons=":-(|:ok:|:-I" showlegend="on" reset="Change all @STATESEL" statesel="on"}%

Status	Item
%CLI%	Text

%CHECKLISTEND%

-- BillGunter - 2011-05-30

Doesn't seem to play well with the EDITTABLE plugin. I forgot to include that part in my snippet. If I remove it the display is fine.

-- BillGunter - 2011-05-30