Hi all Continuing with the development of Confluence repository connector [1] I have added support for processing attachments (configurable per job) for pages, ability to crawl each kind of pages and extract the page labels if they have been set. Besides, a complete refactor of the code and client has been done, so now the connector has a better code flow and the specific components have been simplified. Right now, the connector is able to process Page and attachments, being Page each supported confluence page type (blog, table, etc). As an improvement I want to add specific support for each kind of Page, giving the connector the ability to process Page-specific features. For example, for Blog pages, the connector is extracting the default/common properties, but adding the specific support for Blog page model (like it has been done for attachments) would allow to extract Blog page-specific properties and set the specific type for that page to Blog instead of Page (by default).
Another things that is being done in parallel is the development of the tests, to have a complete set of unit tests for the midterm. The code can be found at [1]. It is a git branch. After the midterm, I will merge that branch with master one and create another one for the development of the authority connector to keep them separated at the moment. If you have any question/suggestion/comment, please drop a message here which will be more than welcome. Regards -- [1] https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/repository-connector 2015-06-05 18:48 GMT+02:00 Antonio David Pérez Morales < adperezmora...@gmail.com>: > 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 > api. > > 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. > > Regards > > > [1] https://github.com/adperezmorales/confluence-manifold-connector/ > > 2015-05-26 17:10 GMT+02:00 Antonio David Pérez Morales < > adperezmora...@gmail.com>: > >> 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 >> > >
