You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Antonio David Pérez Morales <ad...@gmail.com> on 2015/07/08 18:31:36 UTC
[GSoC] Confluence Authority Connector
Hi devs
After the midterm, I continue with the proposed work and I already started
to work on the second part of the project, which is the development of an
Authority Connector for Confluence.
I have created a new branch [1] for that in my GitHub account and I already
committed the basic structure of the connector along with the code related
to Confluence instance configuration. After that I will develop the proper
strategy to get the ACLs for the user as stated in the proposal.
For this case, I have been evaluating the two scenarios contained in the
proposal and I will start developing the space-based permissions which
requires no customizations of Confluence instance (coarse grain).
I made some tests with Confluence APIs trying to go more fine-grain using
the user groups but there is not endpoint method to get the groups that can
view a specific page. So in the end, I think the space-based permission is
a good solution, because implementing a Confluence plugin for that to cover
some very specific use cases I think most people won't be willing to patch
Confluence only for those specific use cases (for example where a person is
not allowed to view a space but it is allowed to view a single page in that
space).
I have also updated the README file putting a guide to configure both
connectors using screenshots about configuration tabs for the connectors.
I'm using embedded images (using Data URIs syntax for images) but it seems
they are not supported by GitHub in the README (although they are in the
code, and other Markdown viewers can show them).
The connectors are in separated branches until I merge them into master.
Moreover, I have been talking and reviewing with Rafa through Skype the
current work, and we have agreed to track all the things also in the Jira
issue (apart from these mails), so I will put the configuration screenshots
there and the links to the GitHub repositories.
Comments and suggestions are more than welcome as always.
Regards
--------
[1]
https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
Re: [GSoC] Confluence Authority Connector
Posted by Antonio David Pérez Morales <ad...@gmail.com>.
Hi Karl
I think so as well. So I will go for the first proposed solution that will
bring us permissions at space level.
Thanks for your response
Regards
2015-07-08 18:55 GMT+02:00 Karl Wright <da...@gmail.com>:
> "I made some tests with Confluence APIs trying to go more fine-grain using
> the user groups but there is not endpoint method to get the groups that can
> view a specific page."
>
> Hi Antonio,
> I had a very similar problem with Jira. It's not apparently possible to
> get back a list of groups for a user without writing a special plugin that
> runs on Jira. This may be a common feature of all Atlassian software.
>
> Karl
>
>
> On Wed, Jul 8, 2015 at 12:31 PM, Antonio David Pérez Morales <
> adperezmorales@gmail.com> wrote:
>
> > Hi devs
> >
> > After the midterm, I continue with the proposed work and I already
> started
> > to work on the second part of the project, which is the development of an
> > Authority Connector for Confluence.
> >
> > I have created a new branch [1] for that in my GitHub account and I
> already
> > committed the basic structure of the connector along with the code
> related
> > to Confluence instance configuration. After that I will develop the
> proper
> > strategy to get the ACLs for the user as stated in the proposal.
> >
> > For this case, I have been evaluating the two scenarios contained in the
> > proposal and I will start developing the space-based permissions which
> > requires no customizations of Confluence instance (coarse grain).
> >
> > I made some tests with Confluence APIs trying to go more fine-grain using
> > the user groups but there is not endpoint method to get the groups that
> can
> > view a specific page. So in the end, I think the space-based permission
> is
> > a good solution, because implementing a Confluence plugin for that to
> cover
> > some very specific use cases I think most people won't be willing to
> patch
> > Confluence only for those specific use cases (for example where a person
> is
> > not allowed to view a space but it is allowed to view a single page in
> that
> > space).
> >
> > I have also updated the README file putting a guide to configure both
> > connectors using screenshots about configuration tabs for the connectors.
> > I'm using embedded images (using Data URIs syntax for images) but it
> seems
> > they are not supported by GitHub in the README (although they are in the
> > code, and other Markdown viewers can show them).
> >
> > The connectors are in separated branches until I merge them into master.
> >
> > Moreover, I have been talking and reviewing with Rafa through Skype the
> > current work, and we have agreed to track all the things also in the Jira
> > issue (apart from these mails), so I will put the configuration
> screenshots
> > there and the links to the GitHub repositories.
> >
> > Comments and suggestions are more than welcome as always.
> >
> > Regards
> >
> > --------
> >
> > [1]
> >
> >
> https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
> >
>
Re: [GSoC] Confluence Authority Connector
Posted by Karl Wright <da...@gmail.com>.
"I made some tests with Confluence APIs trying to go more fine-grain using
the user groups but there is not endpoint method to get the groups that can
view a specific page."
Hi Antonio,
I had a very similar problem with Jira. It's not apparently possible to
get back a list of groups for a user without writing a special plugin that
runs on Jira. This may be a common feature of all Atlassian software.
Karl
On Wed, Jul 8, 2015 at 12:31 PM, Antonio David Pérez Morales <
adperezmorales@gmail.com> wrote:
> Hi devs
>
> After the midterm, I continue with the proposed work and I already started
> to work on the second part of the project, which is the development of an
> Authority Connector for Confluence.
>
> I have created a new branch [1] for that in my GitHub account and I already
> committed the basic structure of the connector along with the code related
> to Confluence instance configuration. After that I will develop the proper
> strategy to get the ACLs for the user as stated in the proposal.
>
> For this case, I have been evaluating the two scenarios contained in the
> proposal and I will start developing the space-based permissions which
> requires no customizations of Confluence instance (coarse grain).
>
> I made some tests with Confluence APIs trying to go more fine-grain using
> the user groups but there is not endpoint method to get the groups that can
> view a specific page. So in the end, I think the space-based permission is
> a good solution, because implementing a Confluence plugin for that to cover
> some very specific use cases I think most people won't be willing to patch
> Confluence only for those specific use cases (for example where a person is
> not allowed to view a space but it is allowed to view a single page in that
> space).
>
> I have also updated the README file putting a guide to configure both
> connectors using screenshots about configuration tabs for the connectors.
> I'm using embedded images (using Data URIs syntax for images) but it seems
> they are not supported by GitHub in the README (although they are in the
> code, and other Markdown viewers can show them).
>
> The connectors are in separated branches until I merge them into master.
>
> Moreover, I have been talking and reviewing with Rafa through Skype the
> current work, and we have agreed to track all the things also in the Jira
> issue (apart from these mails), so I will put the configuration screenshots
> there and the links to the GitHub repositories.
>
> Comments and suggestions are more than welcome as always.
>
> Regards
>
> --------
>
> [1]
>
> https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
>
Re: [GSoC] Confluence Authority Connector
Posted by Antonio David Pérez Morales <ad...@gmail.com>.
Hi Karl
Thanks for your response.
No, I'm not using document components, so I will change the call to
checkDocumentNeedsReindexing.
Only for curiosity, do you have any example showing how to use document
components with the RepositoryDocument model used in Manifold?
Regards
2015-07-11 1:19 GMT+02:00 Karl Wright <da...@gmail.com>:
> bq. Karl one question about repository connector document retainment. I'm
> using
> the activities.retainAllComponentDocument(docId) method of IProcessActivity
> to retain the document and avoid to be reindexed.
>
> Hi Antonio,
>
> checkDocumentNeedsReindexing() is the standard way of determining whether a
> document needs to be reindexed or not. You can follow the template present
> in multiple other connectors that use this method.
>
> retainAllComponentDocuments() is basically a shorthand way of determining
> the disposition of document components. I don't believe you even use
> document components in the confluence connector, although I could be wrong
> about that? In general, if your connector doesn't do anything with
> components at all, you will not need to call this method.
>
> Thanks,
> Karl
>
>
>
>
> On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales <
> adperezmorales@gmail.com> wrote:
>
> > Hi devs
> >
> > Continuing with the work, I have developed a first version of the
> > Confluence Authority connector aligned with the ACLs used by the
> Confluence
> > Repository Connector.
> > I have fixed and improved some parts in the repository connector and
> > committed the code and also I have updated the Jira issue [1] to keep
> track
> > of the new additions.
> > Both branches have been merged into master and I have created a new
> develop
> > branch [2] from it, so further improvements and fixes can be done from
> this
> > branch and then merged into master.
> > Right now, the connectors are in different maven modules and maybe in the
> > future I can merge into one single maven project without modules, so that
> > with one jar file we will have both connectors ready to be used in
> > Manifold.
> > As of now, I will work in the Authority connector improvements and tests
> > and also I will do all the things Rafa (or you guys) can report regarding
> > the functionality of the connectors.
> >
> > Karl one question about repository connector document retainment. I'm
> using
> > the activities.retainAllComponentDocument(docId) method of
> IProcessActivity
> > to retain the document and avoid to be reindexed.
> > Rafa, while checking and reviewing the code, noticed that other
> connectors
> > are using the checkDocumentNeedsReindexing(documentIdentifier,
> > newVersionString) method also from IProcessActivity. I checked the code
> > from both methods and internally they act differently. Is it fine to use
> > the retainAllComponentDocument or it is better to switch to
> > checkDocumentNeedsReindexing one?
> >
> > As always, if you have suggestions about improvements or more things
> which
> > can be done for these connectors, please let me know.
> >
> > Regards
> >
> > [1] https://issues.apache.org/jira/browse/CONNECTORS-1161
> > [2]
> >
> >
> https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
> >
> >
> > 2015-07-09 17:17 GMT+02:00 Rafa Haro <rh...@apache.org>:
> >
> > > Hi Antonio,
> > >
> > > Thanks for the new update. Let me make some comments inline:
> > >
> > > On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales <
> > > adperezmorales@gmail.com> wrote:
> > >
> > > > Hi devs
> > > >
> > > > After the midterm, I continue with the proposed work and I already
> > > started
> > > > to work on the second part of the project, which is the development
> of
> > an
> > > > Authority Connector for Confluence.
> > > >
> > > > I have created a new branch [1] for that in my GitHub account and I
> > > already
> > > > committed the basic structure of the connector along with the code
> > > related
> > > > to Confluence instance configuration. After that I will develop the
> > > proper
> > > > strategy to get the ACLs for the user as stated in the proposal.
> > > >
> > > > For this case, I have been evaluating the two scenarios contained in
> > the
> > > > proposal and I will start developing the space-based permissions
> which
> > > > requires no customizations of Confluence instance (coarse grain).
> > > >
> > > > I made some tests with Confluence APIs trying to go more fine-grain
> > using
> > > > the user groups but there is not endpoint method to get the groups
> that
> > > can
> > > > view a specific page. So in the end, I think the space-based
> permission
> > > is
> > > > a good solution, because implementing a Confluence plugin for that to
> > > cover
> > > > some very specific use cases I think most people won't be willing to
> > > patch
> > > > Confluence only for those specific use cases (for example where a
> > person
> > > is
> > > > not allowed to view a space but it is allowed to view a single page
> in
> > > that
> > > > space).
> > > >
> > >
> > > Let's focus right now on permissions at space level. As you said, to
> > patch
> > > confluence API is not a good solution, specially for those using it in
> > the
> > > Cloud. If in the future they extend the API with more fine grained
> > > permissions approach, we can always update later the connector.
> > >
> > >
> > > >
> > > > I have also updated the README file putting a guide to configure both
> > > > connectors using screenshots about configuration tabs for the
> > connectors.
> > > > I'm using embedded images (using Data URIs syntax for images) but it
> > > seems
> > > > they are not supported by GitHub in the README (although they are in
> > the
> > > > code, and other Markdown viewers can show them).
> > > >
> > >
> > > Ok, thanks!
> > >
> > >
> > > >
> > > > The connectors are in separated branches until I merge them into
> > master.
> > > >
> > > > Moreover, I have been talking and reviewing with Rafa through Skype
> the
> > > > current work, and we have agreed to track all the things also in the
> > Jira
> > > > issue (apart from these mails), so I will put the configuration
> > > screenshots
> > > > there and the links to the GitHub repositories.
> > > >
> > >
> > > Perfect!. Let me know when we can start testing the Authority connector
> > > too. My intention is to test the whole connector in a real environment
> > > extensively sometime before the pencil downs looking for possible bugs,
> > > additions and so on.
> > >
> > > Well done so far!
> > > Cheers,
> > > Rafa
> > >
> > >
> > > >
> > > > Comments and suggestions are more than welcome as always.
> > > >
> > > > Regards
> > > >
> > > > --------
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
> > > >
> > >
> >
>
Re: [GSoC] Confluence Authority Connector
Posted by Karl Wright <da...@gmail.com>.
bq. Karl one question about repository connector document retainment. I'm
using
the activities.retainAllComponentDocument(docId) method of IProcessActivity
to retain the document and avoid to be reindexed.
Hi Antonio,
checkDocumentNeedsReindexing() is the standard way of determining whether a
document needs to be reindexed or not. You can follow the template present
in multiple other connectors that use this method.
retainAllComponentDocuments() is basically a shorthand way of determining
the disposition of document components. I don't believe you even use
document components in the confluence connector, although I could be wrong
about that? In general, if your connector doesn't do anything with
components at all, you will not need to call this method.
Thanks,
Karl
On Fri, Jul 10, 2015 at 10:43 AM, Antonio David Pérez Morales <
adperezmorales@gmail.com> wrote:
> Hi devs
>
> Continuing with the work, I have developed a first version of the
> Confluence Authority connector aligned with the ACLs used by the Confluence
> Repository Connector.
> I have fixed and improved some parts in the repository connector and
> committed the code and also I have updated the Jira issue [1] to keep track
> of the new additions.
> Both branches have been merged into master and I have created a new develop
> branch [2] from it, so further improvements and fixes can be done from this
> branch and then merged into master.
> Right now, the connectors are in different maven modules and maybe in the
> future I can merge into one single maven project without modules, so that
> with one jar file we will have both connectors ready to be used in
> Manifold.
> As of now, I will work in the Authority connector improvements and tests
> and also I will do all the things Rafa (or you guys) can report regarding
> the functionality of the connectors.
>
> Karl one question about repository connector document retainment. I'm using
> the activities.retainAllComponentDocument(docId) method of IProcessActivity
> to retain the document and avoid to be reindexed.
> Rafa, while checking and reviewing the code, noticed that other connectors
> are using the checkDocumentNeedsReindexing(documentIdentifier,
> newVersionString) method also from IProcessActivity. I checked the code
> from both methods and internally they act differently. Is it fine to use
> the retainAllComponentDocument or it is better to switch to
> checkDocumentNeedsReindexing one?
>
> As always, if you have suggestions about improvements or more things which
> can be done for these connectors, please let me know.
>
> Regards
>
> [1] https://issues.apache.org/jira/browse/CONNECTORS-1161
> [2]
>
> https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
>
>
> 2015-07-09 17:17 GMT+02:00 Rafa Haro <rh...@apache.org>:
>
> > Hi Antonio,
> >
> > Thanks for the new update. Let me make some comments inline:
> >
> > On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales <
> > adperezmorales@gmail.com> wrote:
> >
> > > Hi devs
> > >
> > > After the midterm, I continue with the proposed work and I already
> > started
> > > to work on the second part of the project, which is the development of
> an
> > > Authority Connector for Confluence.
> > >
> > > I have created a new branch [1] for that in my GitHub account and I
> > already
> > > committed the basic structure of the connector along with the code
> > related
> > > to Confluence instance configuration. After that I will develop the
> > proper
> > > strategy to get the ACLs for the user as stated in the proposal.
> > >
> > > For this case, I have been evaluating the two scenarios contained in
> the
> > > proposal and I will start developing the space-based permissions which
> > > requires no customizations of Confluence instance (coarse grain).
> > >
> > > I made some tests with Confluence APIs trying to go more fine-grain
> using
> > > the user groups but there is not endpoint method to get the groups that
> > can
> > > view a specific page. So in the end, I think the space-based permission
> > is
> > > a good solution, because implementing a Confluence plugin for that to
> > cover
> > > some very specific use cases I think most people won't be willing to
> > patch
> > > Confluence only for those specific use cases (for example where a
> person
> > is
> > > not allowed to view a space but it is allowed to view a single page in
> > that
> > > space).
> > >
> >
> > Let's focus right now on permissions at space level. As you said, to
> patch
> > confluence API is not a good solution, specially for those using it in
> the
> > Cloud. If in the future they extend the API with more fine grained
> > permissions approach, we can always update later the connector.
> >
> >
> > >
> > > I have also updated the README file putting a guide to configure both
> > > connectors using screenshots about configuration tabs for the
> connectors.
> > > I'm using embedded images (using Data URIs syntax for images) but it
> > seems
> > > they are not supported by GitHub in the README (although they are in
> the
> > > code, and other Markdown viewers can show them).
> > >
> >
> > Ok, thanks!
> >
> >
> > >
> > > The connectors are in separated branches until I merge them into
> master.
> > >
> > > Moreover, I have been talking and reviewing with Rafa through Skype the
> > > current work, and we have agreed to track all the things also in the
> Jira
> > > issue (apart from these mails), so I will put the configuration
> > screenshots
> > > there and the links to the GitHub repositories.
> > >
> >
> > Perfect!. Let me know when we can start testing the Authority connector
> > too. My intention is to test the whole connector in a real environment
> > extensively sometime before the pencil downs looking for possible bugs,
> > additions and so on.
> >
> > Well done so far!
> > Cheers,
> > Rafa
> >
> >
> > >
> > > Comments and suggestions are more than welcome as always.
> > >
> > > Regards
> > >
> > > --------
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
> > >
> >
>
Re: [GSoC] Confluence Authority Connector
Posted by Antonio David Pérez Morales <ad...@gmail.com>.
Hi devs
Continuing with the work, I have developed a first version of the
Confluence Authority connector aligned with the ACLs used by the Confluence
Repository Connector.
I have fixed and improved some parts in the repository connector and
committed the code and also I have updated the Jira issue [1] to keep track
of the new additions.
Both branches have been merged into master and I have created a new develop
branch [2] from it, so further improvements and fixes can be done from this
branch and then merged into master.
Right now, the connectors are in different maven modules and maybe in the
future I can merge into one single maven project without modules, so that
with one jar file we will have both connectors ready to be used in Manifold.
As of now, I will work in the Authority connector improvements and tests
and also I will do all the things Rafa (or you guys) can report regarding
the functionality of the connectors.
Karl one question about repository connector document retainment. I'm using
the activities.retainAllComponentDocument(docId) method of IProcessActivity
to retain the document and avoid to be reindexed.
Rafa, while checking and reviewing the code, noticed that other connectors
are using the checkDocumentNeedsReindexing(documentIdentifier,
newVersionString) method also from IProcessActivity. I checked the code
from both methods and internally they act differently. Is it fine to use
the retainAllComponentDocument or it is better to switch to
checkDocumentNeedsReindexing one?
As always, if you have suggestions about improvements or more things which
can be done for these connectors, please let me know.
Regards
[1] https://issues.apache.org/jira/browse/CONNECTORS-1161
[2]
https://github.com/adperezmorales/confluence-manifold-connector/tree/develop
2015-07-09 17:17 GMT+02:00 Rafa Haro <rh...@apache.org>:
> Hi Antonio,
>
> Thanks for the new update. Let me make some comments inline:
>
> On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales <
> adperezmorales@gmail.com> wrote:
>
> > Hi devs
> >
> > After the midterm, I continue with the proposed work and I already
> started
> > to work on the second part of the project, which is the development of an
> > Authority Connector for Confluence.
> >
> > I have created a new branch [1] for that in my GitHub account and I
> already
> > committed the basic structure of the connector along with the code
> related
> > to Confluence instance configuration. After that I will develop the
> proper
> > strategy to get the ACLs for the user as stated in the proposal.
> >
> > For this case, I have been evaluating the two scenarios contained in the
> > proposal and I will start developing the space-based permissions which
> > requires no customizations of Confluence instance (coarse grain).
> >
> > I made some tests with Confluence APIs trying to go more fine-grain using
> > the user groups but there is not endpoint method to get the groups that
> can
> > view a specific page. So in the end, I think the space-based permission
> is
> > a good solution, because implementing a Confluence plugin for that to
> cover
> > some very specific use cases I think most people won't be willing to
> patch
> > Confluence only for those specific use cases (for example where a person
> is
> > not allowed to view a space but it is allowed to view a single page in
> that
> > space).
> >
>
> Let's focus right now on permissions at space level. As you said, to patch
> confluence API is not a good solution, specially for those using it in the
> Cloud. If in the future they extend the API with more fine grained
> permissions approach, we can always update later the connector.
>
>
> >
> > I have also updated the README file putting a guide to configure both
> > connectors using screenshots about configuration tabs for the connectors.
> > I'm using embedded images (using Data URIs syntax for images) but it
> seems
> > they are not supported by GitHub in the README (although they are in the
> > code, and other Markdown viewers can show them).
> >
>
> Ok, thanks!
>
>
> >
> > The connectors are in separated branches until I merge them into master.
> >
> > Moreover, I have been talking and reviewing with Rafa through Skype the
> > current work, and we have agreed to track all the things also in the Jira
> > issue (apart from these mails), so I will put the configuration
> screenshots
> > there and the links to the GitHub repositories.
> >
>
> Perfect!. Let me know when we can start testing the Authority connector
> too. My intention is to test the whole connector in a real environment
> extensively sometime before the pencil downs looking for possible bugs,
> additions and so on.
>
> Well done so far!
> Cheers,
> Rafa
>
>
> >
> > Comments and suggestions are more than welcome as always.
> >
> > Regards
> >
> > --------
> >
> > [1]
> >
> >
> https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
> >
>
Re: [GSoC] Confluence Authority Connector
Posted by Rafa Haro <rh...@apache.org>.
Hi Antonio,
Thanks for the new update. Let me make some comments inline:
On Wed, Jul 8, 2015 at 6:31 PM, Antonio David Pérez Morales <
adperezmorales@gmail.com> wrote:
> Hi devs
>
> After the midterm, I continue with the proposed work and I already started
> to work on the second part of the project, which is the development of an
> Authority Connector for Confluence.
>
> I have created a new branch [1] for that in my GitHub account and I already
> committed the basic structure of the connector along with the code related
> to Confluence instance configuration. After that I will develop the proper
> strategy to get the ACLs for the user as stated in the proposal.
>
> For this case, I have been evaluating the two scenarios contained in the
> proposal and I will start developing the space-based permissions which
> requires no customizations of Confluence instance (coarse grain).
>
> I made some tests with Confluence APIs trying to go more fine-grain using
> the user groups but there is not endpoint method to get the groups that can
> view a specific page. So in the end, I think the space-based permission is
> a good solution, because implementing a Confluence plugin for that to cover
> some very specific use cases I think most people won't be willing to patch
> Confluence only for those specific use cases (for example where a person is
> not allowed to view a space but it is allowed to view a single page in that
> space).
>
Let's focus right now on permissions at space level. As you said, to patch
confluence API is not a good solution, specially for those using it in the
Cloud. If in the future they extend the API with more fine grained
permissions approach, we can always update later the connector.
>
> I have also updated the README file putting a guide to configure both
> connectors using screenshots about configuration tabs for the connectors.
> I'm using embedded images (using Data URIs syntax for images) but it seems
> they are not supported by GitHub in the README (although they are in the
> code, and other Markdown viewers can show them).
>
Ok, thanks!
>
> The connectors are in separated branches until I merge them into master.
>
> Moreover, I have been talking and reviewing with Rafa through Skype the
> current work, and we have agreed to track all the things also in the Jira
> issue (apart from these mails), so I will put the configuration screenshots
> there and the links to the GitHub repositories.
>
Perfect!. Let me know when we can start testing the Authority connector
too. My intention is to test the whole connector in a real environment
extensively sometime before the pencil downs looking for possible bugs,
additions and so on.
Well done so far!
Cheers,
Rafa
>
> Comments and suggestions are more than welcome as always.
>
> Regards
>
> --------
>
> [1]
>
> https://github.com/adperezmorales/confluence-manifold-connector/tree/feature/authority-connector
>