how to get the static Page ID of the "CURRENT" / Head Version of a page

[Karsten Aalders]

I'm looking for a way to get the Page ID of a confluence page.

There are already several solutions discussed here (e.g. see here: 

Solved: Get/display Page ID - Confluence Internal Code)

But this solutions seem to work only for "non-headrevision" pages.

It appears, that the latest version of a page has always the same Page ID, so that ID seem to always address the "Head" revision of a page, regardless how often it is changed, what might be useful as well, but is in in this case not what I'm looking for.

My use case is, that I want to include the Page ID in a printout of a document (I know: archaic, don't ask me why...) , so it is possible to identify the exact version of the page printed by its page ID.

Quite often, this is the latest version of such page while printout, that might become updated with new information later on. It is important for me to later use the printout to identify the exact version of the printed page at any time in the future.

I already created a macro to include this information in the page but found, that this works only for "older"/"non head" versions of the page.  Such pages show a static/unique Page ID that address a specific version of the page, while a printout of the latest version of the page (=> head version) shows an Page ID that dynamically addresses always the latest version of the page, so it is not possible to identify a specific page version that was the "head version" of that page while printout. OK, you can somehow figure out what page version was printed by looking at the page history and the print date... but that can't be the only solution here (at least I hope...) 

Anny suggestions?

Thank you in advance!

[Mirek · Accepted solution]

On the other hand now when I am thinking about it more..

What if we could simply use version number as an unique ID of a specific page? It is always unique even you remove old version of a page...

and we can refer to it by an unique URL also.. 

https://<base URL>/pages/viewpage.action?pageId=<currentPageID>&pageVersion=<versionNumber>

So then we only need to remember main ID of the page which would never change and its version which could be easily printed also in a macro by calling "$content.version"

Example:

## @noparams

This is version <b>$content.version</b> which was saved on <b>$content.lastModificationDate</b>

Including this on a page or generating a URL based on CURRENT ID with Version should always refer back to specific page no matter if ID change when a new version would be rolled out or not.

https://<base URL>/pages/viewpage.action?pageId=1234567890&pageVersion=22

and

https://<base URL>/pages/viewpage.action?pageId=1234567890&pageVersion=1

should do the job without the need to know historical ID 

[Mirek · Accepted solution]

Hi @Karsten Aalders 

I think getting the page ID from DB is quite easy (including current and historical content) but from what I understand you want to include that information on the page, correct? If so there was a way (I think using Script Runner for Confluence) but not sure if this would be ideal for your specific case.. 

[Karsten Aalders]

Yes I need to include the Page ID visible on the Page itself...

Some background about my use case:

We use Confluence, to document requirements for our products. 

Due to regulatory and internal quality regulations, we need to provide "frozen PDF printout" versions of such requirements, so we use some macros to create PDFs from our Confluence based documentation.

This is usually performed at a given point in time

( e.g. for a pending product release:

- printout

- sign it

- put it on the shelf to collect dust

- please don't ask... ).

After that, we might continue to work on our confluence based requirement documentation (e.g. to add/change features for the next release) by adding or changing information provided, what results in new versions of the confluence documents/pages affected, that might be then printed for the next release.

The challenge now is, to be able to later identify the exact Confluence Page/Document/Version that was once "printed" in the past by information provided by that "printout"...

That could be the exact page ID of the "printed" Page/Document/Version that must then be included as readable ("printable"... :-)) text as part of the document printed.

The thread I linked above (Solved: Get/display Page ID - Confluence Internal Code)) seems to "almost" provide a solution for this since it provides the Page ID of a given confluence page... but only for all "historic" versions of a confluence page, but NOT for the latest/head version.

For the latest/head version of a confluence page, the Page ID returned by that solution is the Page ID that (now and in the future) will address the moving latest/head version of that confluence page (including all changes made until then). So at time of the "printout" the ID might be correct, but in the future (after changes are made to the confluence page that was printed) the ID does no longer identify the exact "printed" version of the page, but the one that is then the latest/head version of that page, including all changes made after the "printout".

So it seems, confluence can provide an unique ID for any historic page versions that are static for each historic page version, and a unique ID for the latest/head version of a given page that will always address the latest/head version of a given page.

What I'm looking for is a mechanism to get a static ID for the exact page version that is stored as latest/head version in confluence at the time the page ID is fetched (e.g. for PDF  "printout". Basically it might be the latest/head version of a page at "print" time, but it might become a "historic" version after some changes are made to that page... I need the unique page ID to address that then "historic" version.

I find all this hard to describe in detail, but the basics are actually quite simple:

I need to include information in a HEAD version confluence page printout, that allows me to identify the exact version of that confluence page printed in the future, regardless what was changed on that page after that printout

Thanks for your support in advance :-)

[marc -Collabello--Phase Locked-]

We offer this on Confluence Cloud with a macro:  Document Metadata for Confluence Cloud .  You can also include the last edit date/timestamp.

This might actually help you on DC:  Instead of focusing only on pageid, use the last edit timestamp to identify the exact version?

[Karsten Aalders]

Hi Marc,

I wonder if the Page ID in Document Metadata for Confluence Cloud isn't the same ID as accessible via the Macro way described in Solved: Get/display Page ID - Confluence Internal Code) and shows the same behavior that I described above.... and then: I can not use a Confluence Cloud solution :-)

Working with the print date seems to be a "Mr. Flintstone" approach when using a tool like Confluence.... plus: even that seem to be not really supporten since for that I would need to always show the "HEAD" ID of that page in the "PDF printout"... what seem to work only for the HEAD / most resent version of a confluence page. Historic Versions would show their unique page ID instead, what is then not shown on the "PDF printout", so for an auditor, the "historic" confluence page/"PDF printout" documents are not the same => game over....

[marc -Collabello--Phase Locked-]

I agree that the document timestamp can be seen as a workaround.  However, at least in Confluence Cloud, document ids will change if you export and then import content into another Confluence instance.  That means an old PDF printout will not cross-reference with e.g. a new backup copy of your Confluence content.

One thing we advise our customers (on Cloud) is to include the complete URL of the document into the printout.  This URL also contains the document id and the cloud instance.  This is what our Document Metadata addon does (among other things).

In data center it is somewhat different, as your admin can take a database snapshot and can ensure integrity in this way.

[Mirek]

Yes, I think when you print a web page from a browser by default it should show the URL on the footer, right? 

If that is not enough I refer back to the idea of using DB.. I think ID is correct and unique when looking at the DB tables.. 

https://confluence.atlassian.com/confkb/how-to-obtain-a-list-of-all-pages-their-authors-and-related-information-from-the-confluence-database-968687591.html

Using CONTENTID value

c.contentid

when parameter is "current" to view latest version

c.content_status = 'current'

 or I guess to have all historical pages

c.content_status != 'current'

 It is only a matter of getting this value on the page to print it (example)

[Mirek]

On the other hand now when I am thinking about it more..

What if we could simply use version number as an unique ID of a specific page? It is always unique even you remove old version of a page...

and we can refer to it by an unique URL also.. 

https://<base URL>/pages/viewpage.action?pageId=<currentPageID>&pageVersion=<versionNumber>

So then we only need to remember main ID of the page which would never change and its version which could be easily printed also in a macro by calling $content.version

Example:

## @noparams

This is version <b>$content.version</b> which was saved on <b>$content.lastModificationDate</b>

Including this on a page or generating a URL based on CURRENT ID with Version should always refer back to specific page no matter if ID change when a new version would be rolled out or not.

https://<base URL>/pages/viewpage.action?pageId=1234567890&pageVersion=22

and

https://<base URL>/pages/viewpage.action?pageId=1234567890&pageVersion=1

should do the job without the need to know historical ID 

[Karsten Aalders]

Hi Mirek,

Thanks for your response, I think this comes closer to what I'm looking for...

My assumption was, that the "Version approach" would run in the same issues as the Page ID approach, since the version list (as you show) Identifies the latest version as CURRENT, showing the Version number only in brackets and not "klickable", but you are correct, your "pageId=1234567890&pageVersion=22" (with Page ID 1234567890 as current page ID, Version 22 as the CURRENT version) works and results in the display of the latest version of that page (I tried it with my own page/versions :-))

I also assumed that your approach would not work for "printing" historic versions of a page since their page ID is not the latest/current/base page ID but a unique one, addressing exactly that one historic page version. So in your example, the Version 11 of your page might have the Page ID 1212121212, thus, https://<base URL>/pages/viewpage.action?pageId=1212121212 would show the "historic" version 11 of your page.

My assumption was, that something like https://<base URL>/pages/viewpage.action?pageId=1212121212&pageVersion=22 would not work, since it basically says "show me version 22 of version 11 of my page" what makes no sense, but it turns out that it... somehow... works out and actually shows version 22 of that page (again: I tried it with my own page/versions :-))

So it seems like someone can use any page ID of a given page (regardless if it is the CURRENT, or any "historic" ID) for accessing/display a given version of that page... can you confirm that? And... is it a bug or a feature :-) ? 

[Karsten Aalders]

Hi Mirek,

Thanks for your response, I think this comes closer to what I'm looking for...

My assumption was, that the "Version approach" would run in the same issues as the Page ID approach, since the version list (as you show) Identifies the latest version as CURRENT, showing the Version number only in brackets and not "klickable", but you are correct, your "pageId=1234567890&pageVersion=22" (with Page ID 1234567890 as current page ID, Version 22 as the CURRENT version) works and results in the display of the latest version of that page (I tried it with my own page/versions :-))

I also assumed that your approach would not work for "printing" historic versions of a page since their page ID is not the latest/current/base page ID but a unique one, addressing exactly that one historic page version. So in your example, the Version 11 of your page might have the Page ID 1212121212, thus, https://<base URL>/pages/viewpage.action?pageId=1212121212 would show the "historic" version 11 of your page.

My assumption was, that something like https://<base URL>/pages/viewpage.action?pageId=1212121212&pageVersion=22 would not work, since it basically says "show me version 22 of version 11 of my page" what makes no sense, but it turns out that it... somehow... works out and actually shows version 22 of that page (again: I tried it with my own page/versions :-))

So it seems like someone can use any page ID of a given page (regardless if it is the CURRENT, or any "historic" ID) for accessing/display a given version of that page... can you confirm that? And... is it a bug or a feature :-) ? 

[Mirek]

Yes, so as I mentioned for you specific case it should work and now you can simply keep for reference CURRENT ID and Version and combine those to view exactly that page that you want. I think that is a pretty stable solution. 

And I do not think it is a bug. We would have to get deeper into DB structure reviewing CONTENT table to see what is happening there when a new version is created.. I guess when you update a page there is a reference that points to the latest version of a page that have a unique ID and current page become historical by changing content_status different value than "current"

content_status = 'current'

[Karsten Aalders]

Yes, I have the same assumption about the ID orgin...

So the Page ID used is actually a "native DB Identifier" that is not under control of Confluence by design.

We implemented a test version of the ID mechanism discussed above and it appeared to work, so now with your confirmation we will change the state to "live" and start to use it in a test/review phase.

The only improvement I can imagine would be to "somehow" always display/use the base page ID, regardless if a "historic" or a CURRENT version of the page is shown, so the page ID is always the same on any "PDF printout"... that would make any auditor happy :-) but I guess that base page ID is not available as native parameter, since it would make the

content_status

parameter redundant...

Anyhow, thanks for your support!

Regards,

Karsten