Opened 17 years ago
Closed 17 years ago
#5741 closed defect (fixed)
InterMapTxt needs reload after updating
Reported by: | Owned by: | Christian Boos | |
---|---|---|---|
Priority: | normal | Milestone: | 0.11 |
Component: | notification | Version: | |
Severity: | major | Keywords: | intermaptxt |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
When entering new links in InterMapTxt you need to reload it once so that Trac catches the changes.
It should be sufficient to edit the page and click Save Changes, otherwise Users might be confused
Attachments (1)
Change History (9)
comment:1 by , 17 years ago
Component: | general → notification |
---|---|
Keywords: | intermaptxt added |
Milestone: | → 0.12 |
Owner: | changed from | to
Priority: | lowest → normal |
Severity: | normal → major |
comment:2 by , 17 years ago
cboos, was notification the intended component within your last change ?
comment:3 by , 17 years ago
Yes, I think the notification component should correspond to the notification infrastructure in general, encompassing the change listeners.
In 0.12, we could even probably implement the e-mail notification component as a simple IxxxChangeListener
(xxx being Ticket for a start).
comment:4 by , 17 years ago
In a current SVN version of trac-0.11 I am seeing behavior where the version of the intermap list displayed by the [[InterWiki]]
macro is sometimes correct and sometimes shows a version of the list that is several revisions old. Sometimes reloading in the browser fixes this, sometimes not.
In all cases, the Prefix Definitions section of the page shows the correct version.
comment:5 by , 17 years ago
I think this feature is actually completely broken, and that the reloading doesn't fix the problem.
I have Trac .11b2 installed. I've added a couple of items to the InterMapTxt wiki page (wiki/InterMapTxt). I've edited the items a couple of times to tweak the URL's. I added several of the InterWiki items on a particular ticket to verify that they work. I got confusing results. If I refresh the ticket using my browser's refresh button, the resulting output from the ticket page will apparently randomly alternate between the Interwiki items 1.) not being recognized as if I'd never changed the wiki/InterMapTxt page 2.) being recognized but handled using an previous version of the wiki/InterMapTxt page, or 3.) being correctly handled by the current version of the wiki/InterMapTxt page. Additionally, I can refresh the wiki/InterMapText page, and I get different results in the "List of Active Prefixes" section, even though the "Prefix Definitions" portion of the page is always correct. I can even do something like: "wiki/InterMapTxt?version=5", and get the same behavior.
This makes the InterWiki link feature unusable completely for any items added over the default items that come out of the box.
comment:6 by , 17 years ago
I have verified that even if only one version of the InterMapTxt file exists, the Interwiki links do not always work. I deleted InterMapTxt and recreated it with the additional prefixes and save them so there was only one version. If I refresh the browsers the Interwiki links will sometimes render and sometimes not.
comment:7 by , 17 years ago
Milestone: | 0.12 → 0.11.1 |
---|---|
Status: | new → assigned |
jjv, it's a known problem in some situations and what you described is explained in comment:1.
Now, since the r6006 fix, there could be a "brute force" way to workaround this problem, namely a config.touch()
in source:trunk/trac/wiki/interwiki.py. Please try out the attached patch.
by , 17 years ago
Attachment: | config-touch-after-intermaptxt-change-r6792.diff added |
---|
Propagate InterMapTxt changes to other servers by the way of a config.touch()
comment:8 by , 17 years ago
Milestone: | 0.11.1 → 0.11 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
In r6837, applied a slightly enhanced patch (protect against race conditions).
I'm still thinking about a more general approach (see TracDev/JournalingProposal), but I think this would do in the meantime.
Yes, it's a known limitation of the (common) multiple server settings. See TracDev/Proposals/Journaling#ReactingonWikicontentchange.
We'll hopefully find a clean and generic way to solve this in the next release.