Flexible WebChanges alternative

Would anybody be interested in something like this? I worked on an alternative to WebChanges, which is faster and more flexible. At the moment it is using the .changes file in $dataDir/$web.

• lib/TWiki/Store.pm needs to be patched to get a fourth column with the DontNotifyFlag
• lib/TWiki.pm needs to be patched to call the sub from %CHANGES%

The attached diffs are against main (rev #1801).

-- OliverKrueger - 02 Nov 2004

I am, just the "honordontnotify" bought me

-- RafaelAlvarez - 02 Nov 2004

This is an excellent idea, but could be made significantly more excellent by the addition of a $diffs option in the format. This would provide a summary of differences. I developed a new TWiki::Merge module for ReleaseLocksOnSave that would provde the perfect HTML for inclusion. It could be limited to a number of lines, or number of characters e.g. $diffs(20c) or $diffs(10l).

-- CrawfordCurrie - 03 Nov 2004

Idealy I'd like to replace the search in WebChangesForAllWebs with this.

If I didn't specify honordontnotify I would like a variable to be able to indicate for a topic if was "don't notify" or not. Maybe something like $dontnotify(y,n) where the first parameter is inserted if it was don't notify and the second if it isn't, so I could do something like $dontnotify(*minor*,*Major*) or $dontnotify(*m*,*M*) or even $dontnotify(,*M*) / $dontnotify(*m*,)

-- SamHasler - 03 Nov 2004

Sam: Feel free to add your code.

-- OliverKrueger - 03 Nov 2004

Maybe we want to start a discussion on setting the limiting value of 100 lines for .changes to a higher value?!

-- OliverKrueger - 03 Nov 2004

It would be nice to have a time/date based limit.

-- SamHasler - 03 Nov 2004

We already thought about a time/date based limit, but it would not work well with the given data set(100 entries per web in .changes).

E.g. if you include different webs you can´t guarantee they include all changed topics since date x. Since one might be a high traffic web and lists topics from the last day within .changes while the other is a low traffic one with changed topics from the last year.

-- AndreUlrich - 03 Nov 2004

Isn't it in date order though? How hard can it be to find the first line on a given date?

• .changes is ordered by date and this would be very simple. The problem is the limit of topics listed in .changes. As I tried to explain, you can´t guarantee that topic changes from a specific date are included. 100 changes a day would made it impossible to show all topics changed since the last 2 days. -- AndreUlrich - 03 Nov 2004

-- SamHasler - 03 Nov 2004

ah, I hadn't realised that the 100 limit was for what goes into .changes, I thought it was a limit on how many entries were normaly extracted.

Perhaps that could be date based as well?

-- SamHasler - 03 Nov 2004

Moreover I would like to know, why there is a limit of 100 (why not 23 or 42)? Ok, DotChanges should not be a second log file. What was the idea behind this concept when the file was created?

-- OliverKrueger - 04 Nov 2004

Bug found and fixed: Displaying the changes of different webs was not possible (parameter web="web1, web2, web3"). The first web dominated the list.

-- OliverKrueger - 25 Nov 2004

I removed all NOSEARCHALL related stuff and added a TWiki::Func::checkAccessPermission call. Now with web=all you are able to find all changes you are allowed to see.

-- OliverKrueger - 06 Jan 2005

What is the reason to add a new CHANGES variable? It would be more consistent and intuitive to be able to use all of the SEARCH switches.

This could be done with a new order="changed" parameter in SEARCH which takes the data from the .changes file and works similar to the existing order="modified" parameter.

-- PeterThoeny - 28 Jan 2005

You are right. But instead of using a order="changed" which is not very untuitive to me, I would propose using scope="changes" as this looks more like a source than order="". Although the code for searching the topic files is different from the code searching the DotChanges, it would be nice to have something like excludetopic="" or footer="" available in the existing SEARCHes, too.

-- OliverKrueger - 28 Jan 2005