Imported from previous forum
This is already supported in exactly the same way as described by Scott. Just a matter of correct procedure.
A new file uploaded as an "edit" to the same file location will retain its GUID. Its name extension within the URL may appear to be the same, UNLESS the user navigates away from the page, and comes back, in which case the name extension will reflect the new title. The name has no functional significance- the URL ending with the GUID is sufficient. In this case then, it might have been sufficient to just amend the title, if the document itself was unchaged.
When thetitle of the document is amended, the amendment does not propogate into the URL with a simple "page refresh"- it retains its original value until approached anew, but if you navigate away and come back, it will display the correct value for the title, as this is generated dynamically as meta from the page load.
If the file is bookmarked into a hyperlink within a docuement, of into a "Bookmark", without causing the meta to refresh, it will look odd, since the URl displayed in the users browser will still display the old meta. The name after the guid is however just a meta-tag for SEO purposes, the "functional" URL just references the file GUID, which does not change, and the URL would still work.
I think Kathleen may have uploaded the document as a new document, instead of loading it into the same location, which means it was assigned a new GUID AND a new description, and since links to the original document reference an explicit URL based on the GUID, they no longer point to the correct place.
The correct procedure in this case would be:-
To replace and/or rename the file in the same location, using "edit"
To rename the file by changing its title.
Save.
Proactively navigate away, and come back, so as to force the meta to be regenerated as part of the URL displayed in the browser address- it will now display the amended value.
The GUID istelf would not have changed. The meta would change, but only when the the page was reapproached (i.e. not if just page a refresh), but in any case would not have any significance- the correct file would be served, even if the name is incorrect. It just looks like the address is wrong.
So in this instance, replacing the file would have resulted in the URL being unchanged, except that it would have changed from:-
to
The same, or amended file could have been accessed under either of these URls, or indeed just under
http://www.fixtradingcommunity.org/pg/file/fplpo/read/461263/
These URLs will not however now work, as the file was instead deleted and reloaded with a new name, so for this specific file it will be necessary to amend any links to reflect the new GUID.
Suggestion is we review the process with Katherine to provide context, but once you have followed the behaviour described above, its pretty self-explanatory.
The old website assigned a number for documents/URLs that are posted to a Document Category, and that became part of the URL (eg http://fixprotocol.org/documents/371/FIX_4_2_Errata_20010501.pdf where 371 is the document number). The "Update" operation updated the stored content for 371 but kept 371 as the document number -- even if the filename changed as the URL parser really just used the document number to retrieve (eg you could have accessed it even with http://fixprotocol.org/documents/371). This maintained continuity of links to documents.
For the Global Exchanges and Markets Committee, Kathleen initially posted my document under http://www.fixtradingcommunity.org/pg/file/fplpo/read/461263/fix-protocol-ga-deutsche-boerse-market-data-statistics. I asked her for an update yesterday whereby the doc is now available under http://www.fixtradingcommunity.org/pg/file/fplpo/read/354919/fix-protocol-gap-analysis-market-data-statistics. Hence the unique ID changed from 461263 to 354919 although the filename remains unchanged.
By coincidence, my colleagued used the old notification email to access the document and was told that he does not have the rights to do so. I tried it myself and got the same result. I guess this is a general problem of reacting properly to document updates invalidating previously distributed links. I do not know how Kathleen posted the update, i.e. if the system has any knowledge of the "replacement" and could automatically redirect to the new link.
One further note- adopting the procedure recommended above would have resulted in the original notification still working..... even though the meta had changed. There would have been a duplicate notification, but both URLs would effectively be fungible.
We are about to release an enhancement that allows the PO the option of "Save" vs "Save and Notify", so that it is easier to prevent duplicate notifications being re-invoked by a simple edit, in light of feedback that duplicate notifications are annoying!
Hi, I can confirm that the unique identifying url remained the same for this document for the GEXMC meetings. I posted this document first for the meeting on the 9th of September generating this url: http://www.fixtradingcommunity.org/pg/file/fplpo/read/354919/fix-protocol-gap-analysis-market-data-statistics
Last night I edited the post updating the document and adding a comment that this was updated for the meeting on the 26th, the following url was generated for this update: http://www.fixtradingcommunity.org/pg/file/fplpo/read/354919/fix-protocol-gap-analysis-market-data-statistics
You can see that the doc update maintained the unique GUID so the link did not change.
Hanno - I mistakenly posted this document on the GTC page earlier and the url: http://www.fixtradingcommunity.org/pg/file/fplpo/read/461263/fix-protocol-ga-deutsche-boerse-market-data-statistics
was associated with that posting. I believe that is the link that your colleague was referring to.
The update operation that Scott mentioned above appears to be working. Apologies if this caused any confusion and we are all looking forward to the "Save" and "Save and Notify" option implementation.
Thanks Kathleen. That all makes sense. I'll close the corresponding JIRA entry.
Thank you all for the quick clarification. I must admit I had not noticed the difference in the doc name in the two URLs. Remains the minor question of why my colleague got an access violation instead of a message saying that the (GTC) document was not found/no longer exists.
Cannot tell from the URL whether you cannot access it because of no access, or because it does not exist (since Master View Controller intercepts it before access to the underlying file), so the message assumes it exists since it is a correctly formatted site URL, but it cannot be accessed.
That would mean that any access to an outdated or misspelled (I tried http://www.fixtradingcommunity.org/pg/file/fplpo/read/xyz with the same result) link would result in the user believing the link to be valid and approaching FPL to find out why he is not allowed to access the underlying file. That may become a real issue going forward if people use direct links to reference FPL documents.
Sorry Hanno I never responded as the detail of this went int JIRA and discussed with Kathleen in detail there. The point re the message is well taken and we will log that for resolution, and look into making it clear that its not a valid link.
Core behaviour with the URLs and File version etc is however exactly as you specified, and have clarified the procedure to ensure the links keep up with any change to the filename and/or title. It picks up the correct name after the GUID once the page has been "forced refresh" rather than just a page refresh, as page refresh does not reload the URL meta, just re-pages the same underlying source. Ther emay be slight differences in behaviour browser-to-browser too, but it all updates without impacting access.