[PATCH] Add the ability to *not* modify ticket changetime field

[Dalton Barreto]

Hi,

I'm attaching here a patch that adds the ability to perform batch modifications without changing ticket's changetime field.

The motivation to this is the use of BatchModifyPlugin along with TracUnreadPlugin.

TracUnreadPlugin compares ticket's changetime with a last visit timestamp (that the plugin updates on every visit to the ticket) to know if a user has any unread comment.

But sometime there are changes that do not need to apear on everybody Recent changes report.

Could you please review the patch and apply, if appropriate?

Thanks,

[Dalton Barreto]

Add the ability do modify tickets without changing changetime field.

[Dalton Barreto]

The patch was produced from version 0.4.1.

[cna training]

Keep posting stuff like this i really like it

[Dalton Barreto]

Replying to cna training:

Keep posting stuff like this i really like it

Thanks, I hope this gets commited. Let's see.

[CuriousCurmudgeon]

(In [7936]) refs #7048

• Applied patch from daltonmatos with some cosmetic changes to keep with the style of the rest of the plugin.

[CuriousCurmudgeon]

Patch has been applied. Some testing would be appreciated from those that have time.

[Dalton Barreto]

Replying to CuriousCurmudgeon:

(In [7936]) refs #7048

• Applied patch from daltonmatos with some cosmetic changes to keep with the style of the rest of the plugin.

Thanks! I'll update my Trac instance very soon.

[Dalton Barreto]

Thinking about this implementation, since will possible to make modifications that no other user will see, would be a good idea to create a new Trac permisison? This way normal users would still be able do make batch modifications, but this modifications will always be visible to others.

What do you think?

[CuriousCurmudgeon]

(In [7939]) refs #7048

• If no value is submitted for bmod_modify_changetime it will be set to False.

[CuriousCurmudgeon]

The modified date is being set to 40 years ago if you choose not to modify the changetime. I think it has to do with microsecond vs second timestamps.

[CuriousCurmudgeon]

(In [7940]) refs #7048

• Fixed changetime bug. Need to call to_utimestamp instead of to_timestamp. Trac stores timestamps in posix microseconds.
• Bumped the version number to 0.5.0

[anonymous]

Replying to CuriousCurmudgeon:

(In [7940]) refs #7048

• Fixed changetime bug. Need to call to_utimestamp instead of to_timestamp. Trac stores timestamps in posix microseconds.
• Bumped the version number to 0.5.0

Hi, Trac stores timestamps in microseconds only in version 0.12. see: ​http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.12#Timestampstorageindatabase

0.11 still uses seconds resolution. So BatchModifyPlugin 0.5.0 ([7940]) does not work with Trac 0.11:

From the logs:

2010-05-13 08:26:07,397 Trac[loader] ERROR: Skipping "batchmod.web_ui = batchmod.web_ui":
 (can't import "ImportError: cannot import name to_utimestamp")

Please revert to [7939]. Actually [7940] is the patch necessary to make BatchModifyPlugin compatible with the new 0.12 Trac. =)

[CuriousCurmudgeon]

The above comment is correct. I forgot about this change and was testing locally against the Trac trunk. I will revert the change and possibly create a 0.12 version of the plugin as well. This is the first difference between 0.11 and 0.12 that affects this plugin as far as I know.

[CuriousCurmudgeon]

(In [7942]) refs #7048

• Merged r7940 back out. This change is only needed for Trac 0.12. See ​http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.12#Timestampstorageindatabase

[Dalton Barreto]

Replying to CuriousCurmudgeon:

Thaks, and that was me (comment:12), I just forgot to login first. =)

[CuriousCurmudgeon]

(In [7943]) refs #7048

• Created a 0.12 version of the plugin. This version uses microseconds for the timestamps.
• Bumped the version number back to 0.5.0

[CuriousCurmudgeon]

Closing as fixed. This is released with 0.5.0. Please reopen if any problems are found.