Support favpages macro in bridge macros

[snazare]

Describe the solution you'd like
The favpages support was developed recently. Please include it in the confluence bridge macros.

[raphj]

@snazare note that the recent custom development about this likely relies on some custom import from Confluence and is probably not ideally integrated.

Figuring out how to import favorites in the first place would be the hard part that is to be done, and bridges without it would me meaningless, so this dev can't be about importing some work that's already done. It is much more difficult than this.

We are stuck on this topic because:

• We don't really have an equivalent feature in XWiki: we have the Like feature but it's not quite the same thing to like something and to bookmark something.
• in Confluence, favorites are tags set on the pages which are favorites of a users, and the tags belong to the people who added the page as favorite. We don't have such a concept of "tags belonging to people" in XWiki, so we would need some custom behavior in the confluence-xml contrib project, and this custom behavior would be weird without a contrib/standard implementation too.

This dev would require some product work:

• implement favorites / bookmarks
• have apis to add a page as favorite for a given user which we could call from confluence-xml

This is a hard topic that is beyond me. I had rejected it as too hard a year ago and the situation didn't change much.

The bridges would be the easy part when we do have a bookmark feature in XWiki and we can import favorites from Confluence as bookmarks on XWiki.

As you might guess from what I wrote, I'm afraid we are probably not ready to make this feature a proper, generic feature we can generally support for our users.

[raphj]

Favorites will probably not be a standard feature in XWiki, with the goal of avoiding feature creep in XWiki Standard.

@vmassol suggested https://extensions.xwiki.org/xwiki/bin/view/Extension/Favorites%20Application/

This app would need to be supported in some way.

If we are to adopt it for this feature, the difficulty would be to find a way to import the favorites from Confluence to this application.

IIUC, with this extension, favorites are stored as Favorites.Code.FavoritesClass objects in the user profile.
In Confluence, they are stored as labels named "favourite" on pages. In Confluence, labels have owners.

It is currently out of question to use the filter streams API to push these objects in user profiles, because we don't have a way to patch, only to replace the whole document. But confluence-xml is currently purely an input filter stream and it's nice that it is.

We'll need to figure out a way to do this and I don't have an idea on how to deal with this cleanly.

Being able to define custom filter primitives / properties that applications could catch would be very nice. We need to discuss with the product team to have such a feature in the filter streams API.

It could be something like an "extension" event that has an extension ID and then supports basically arbitrary parameters and an arbitrary string content. (@michitux )

I think this would need to be implemented in the standard instance output filter stream api.

Another possibly suggested by @michitux could be to change the favorites application to store favorites in a dedicated space per user, and to store one page per favorite. Then those pages could be created by the importer. But it seems a bit heavy in terms of storage.

We could do this and have a post processing optimisation step that merges the pages into one, as a compromise

I like the custom event output filter stream idea way better.

[raphj]

The new version of Confluence Migrator Pro now imports favorites into the Favorites Application.

the implementation of the favpages bridge will simply be importing the Favorites Application's panel.