manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio David Pérez Morales <>
Subject Re: [GSoC] Confluence connector project status after bonding period
Date Fri, 05 Jun 2015 16:48:44 GMT
Hi devs and all

As part of the development of the Atlassian Confluence connector for
Manifold, I have created a repository [1] on my GitHub account
Moreover I have developed and pushed the first version of the Confluence
repository connector on a branch called 'feature/repository-connector'.
This first version of the repository connector allows to crawl all the
Confluence pages contained in the spaces (only pages), with the possibility
to filter by a space.
At this moment, only one space or all of them can be configured to be
crawled, but I will continue improving the connector adding more features
like configuring more than one space or others you may see interesting to
be added.
The ACLs of the documents crawled are the space it belongs to, so that it
is aligned with the proposal for the Authority connector starting at Space
level and then going more fine grain if necessary.
There are no tests included at this moment, because I'm working on them.

To see if the proposed Authority connector could be developed in a good
way, I have done a quick proof of concept with the logic of it and I was
able to get the spaces which the user has permission to access. So I can
confirm that at space level, we can add permissions to the documents
crawled in order to filter them later on the search engine being used.

One important thing is that the new Confluence REST Api does not include
any endpoints for permissions yet, so legacy API's have to be used for that
while Confluence developers port completely the legacy methods to the new

I will continue improving the repository connector and thinking new
features to be added, but if you think some feature is interesting or good
to have, please let me know and I will take a look in order to include it.

As stated in the proposal, the Authority Connector is planned for the
second part of the project, but I started to work a bit on it to make sure
we can have a general working version and then iteratively improving it.

As always, comments and suggestions are more than welcome.



2015-05-26 17:10 GMT+02:00 Antonio David Pérez Morales <>:

> Hi all
> During the bonding period and these days I have been taking a look and
> familiarizing with Confluence API,
> doing some tests using CURL before start the implementation of the
> repository connector which is the first step as stated in the proposal.
> I have deployed a local instance of Confluence as well, so that I can do
> the development and tests using that instance.
> As stated in the proposal, Confluence is migrating its old APIs (rpc-xml,
> rpc-json) to the new REST API, so all the methods are not migrated yet.
> For getting the changes, fields and content of the documents there won't
> be any problem, but for permissions I have to check more in deep if the new
> REST API already support it.
> If not, we will have to do a mix using the methods provided by the
> rpc-json api for that, and update it when the REST API contains all the
> methods.
> After the first tests, there is no easy way to retrieve the user
> permissions because they are tied to documents and/or spaces. So in order
> to retrieve the user permissions,
> documentId or SpaceId and user have to be provided. I proposed two
> approaches to tackle this, one not so efficient, making many requests to
> Confluence and the other developing a Confluence plugin to get them
> (because at least at Java API level it is possible, but don't know yet what
> kind of permissions it returns)
> So I think, for that part, we can start using (trying) permissions at
> Space level and then try to go finer at document level.
> These problems are mainly related to the second part of the project
> (Authority Connector) but I think it is interesting to put here some
> results after the first overall tests I have performed.
> Regards

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message