It would be really helpful to receive an event when a page can be considered “finalized” so that it can be associated with the equivalent of a classic page in the “published” status.
Can the page_snapshotted event be considered an equivalent to the classic page_updated?
1 Like
HI @DavidMichelson . Thank you for the dialog on this change for live docs.
Our team has two existing connect confluence apps with macros that display differently on preview or display mode. We tested the prototype and discovered that the live pages report “preview” mode to macros, which effectively breaks both of our apps.
It was requested above, but let me repeat the request to make it possible for a way in local page javascript to determine if the macro is in a published page (display/preview) or a live page.
Thank you
Chris
Digital Rose
2 Likes
It would be really helpful to receive an event when a page can be considered “finalized” so that it can be associated with the equivalent of a classic page in the “published” status
If a Live Doc is converted to a Page (and is therefore published), you will be able to use the page_published event.
Can the
page_snapshottedevent be considered an equivalent to the classicpage_updated?
For Live Docs, yes, page_snapshotted can roughly be considered equivalent to page_updated, i.e. when a new version has been finalized. Note that the snapshotted events will likely be more frequent. It’s not directly equivalent, but the closet proxy to the page updated event.
2 Likes
Hi all, I wanted to highlight a section of the RFC that we are curious to get more feedback on.
In the Connect Webhooks & Forge Events for Live Docs section, we mentioned:
Under consideration: We are also considering adding an event for when a Page is converted back into a Live Doc. We would love to hear your feedback whether an event like that would be needed.
Do developers have any thoughts on this?
Hi all, thank so much for your feedback on the RFC. Based on your feedback, I wanted to share the outcomes of this RFC. The discussion will still be unlocked for a few days for any last bits of feedback.
Extension Point Modules
- Based on your feedback, we will not require developers to make Connect app descriptor or Forge manifest updates in order to make their apps using extension point modules appear in Live Docs. That way, customers who are stuck on previous app version will be able to access their apps in Live Docs.
- This means that all apps using extension point modules supported in Live Docs will automatically appear in Live Docs when they are rolled out for general availability (GA).
Timing: We are asking that developers make sure their apps function as desired in Live Docs by May 30, 2025.
API
- The API changes listed in the RFC have already been made available in Developer Canary Program sites.
- Regarding the items that were under consideration:
- We will make sure that subtype is supplied via Forge context as well as AP.context.getContext().
- We will also move forward with a Forge client-side API to get the latest editor content & update it, to allow apps to make instant changes to Live Doc content.
- Timing: For both items above, we are working with the team to understand the work required and will report back with timing.
Connect Webhooks & Forge Events
- The Webhook & Event changes listed in the RFC have already been made available in Developer Canary Program sites.
- Regarding the items that were under consideration:
- We did not hear strong feedback that adding an event / webhook for when a Page is converted to a Live Doc was necessary at this time.
Macros
- Macros will continue to behave as outlined in the RFC.
CQL
- The CQL changes listed in the RFC have already been made available in Developer Canary Program sites.
Other feedback
We also heard other areas of feedback for apps in Live Docs that we do not currently plan to take action on, but will continue to monitor from our developer community.
- Static Content Macros - Desire for output.type to indicate when on a Live Doc & the ability to trigger new renders of a static content macro when editing Live Docs
- Bodied Macros - Desire for a “Done Editing” event & the ability to minimize the size of a container when done editing.
2 Likes
What will be the right channel for us to monitor for a decision / update on these? Will you update this RFC? Somewhere else?
1 Like
We plan to post updates on the Confluence Cloud Changelog. We will also plan to reply to this RFC to boost visibility.
2 Likes
Is this still under consideration? Our app heavily relies on it! Also, will the same or a similar concept also be available in the classic page editor, where you recently decided un “un-glasspane” interactive macros?
Regards
Jasmine
Hi @JasmineMller, yes this is something we plan to support for Forge apps as mentioned in our reply to outlined the outcomes of the RFC!
*Regarding the items that were under consideration:
- We will make sure that subtype is supplied via Forge context as well as AP.context.getContext().
- We will also move forward with a Forge client-side API to get the latest editor content & update it, to allow apps to make instant changes to Live Doc content.
Timing: For both items above, we are working with the team to understand the work required and will report back with timing.
I have experienced some strange behavior with the position of pages when switching between Live Docs and Pages. The position of the page returned by the API changes, which wouldn’t be a problem, but sometimes the new position doesn’t correspond with the displayed positions.
So from the viewpoint of a user everything works normally, they change the type of the page and the order of the pages stays the same, but when using the API, i receive a different order after they changed the page type.
Hi @JakobRenner Thank you for your feedback. To make sure I understand, when looking at a page via API that was changed for example from a Live Doc to a Page, even though it has been changed into a Page, the API still says it’s a Live Doc?
Is there any more detail or screenshots you can share?
No its just the Position that’s the problem. For example initially:
| Page Name (in Order they are displayed) | Page type | position value from the API |
|---|---|---|
| Page A | page | 1000 |
| Page B | page | 2000 |
| Page C | page | 3000 |
Then i change Page B to Live Doc
| Page Name (in Order they are displayed) | Page type | position value from the API |
|---|---|---|
| Page A | page | 1000 |
| Page B | Live Doc | 900 |
| Page C | page | 3000 |
The order they get displayed in, in the fronted is still A->B->C but when using the API it’s B->A->C
Thank you for sharing that deep level of detail @JakobRenner ! I see what you’re saying.
Could you also share how this may negatively impact the use case you are working on?
I am working on an internal App that among other things copies pages between Spaces and with this Problem, I can’t move them to the same order as they are in the original space.
Sidenote: having the ability to just set the position of a page when creating it with the API would be a lot more convenient, then having to use the move page before/after route.
Under consideration: Adding a client-side API to get the latest editor content & update it, to allow apps to make instant changes to Live Doc content.
This is good to see - presently, features that need to work with the content of the page directly have issues where there is a lag between the user updating the content and the Content rest api actually reporting those changes. This has always been true to some degree on regular pages, but on live pages the delay seems more variable and potentially much higher. This is dangerous in cases where you are updating the page, because you can wipe out the most recently added content. Will this new API solve this issue by providing more immediate GET and PUT type operations without this lag?
Although, such an API being available only on Forge would not be ideal for us, as we’re still in the process of moving features to Forge and will be for some time.
1 Like
Hi @DavidMichelson,
Are the events in the “Forge Events for Live Docs” section considered final now? I still can’t see the published event in the log when switching back and forth between the Live Doc and normal page modes (and editing the page in both modes).
Hi!
Is there still going to be a property in both descriptor and manifest to disable modules when livedocs is activated?
We have a byline item module that we want to hide for now. At least until we clarify how can we take advantage of this functionality for our app.
Hello, is the mentioned showsInLiveDocs property for the connect descriptor / forge manifest already implemented, or is still a provisional name? If not implemented, maybe it could be proposed as a new display condition (i.e. { "condition": "is_livedoc" }) or a parameter for the preexisting condition has_page (i.e. { "condition": "has_page", "params": { "subtype": "livedoc" } })
Hi @ImanolObaldia @naiara, thanks for your questions. We recently added a ‘resolution’ to this RFC where we stated we will not be moving forward with such a property. See the comment here for more details.
@GaborDicsoMidori Yes these events are now considered final!
See this post for the finalized version of this RFC: Please test & update your Confluence Cloud apps to function in Live docs by May 30, 2025
Are you seeing other live doc specific events like avi:confluence:started:page and avi:confluence:snapshotted:page?