Hi Manoj, Yes, that sounds like some progress, good!
You need to send a put request with the updated administrator role containing your new permission group id in the permission list as payload to the /identity/v1/roles/administrator endpoint. See the RoleRestController in the identity project. Best, Robert Elles Head of Global Product Development Kuelap, Inc. +4915788460030 [email protected] www.kuelap.io Pappelallee 78-79, 10437 Berlin, Germany [image: linkedin] <https://www.linkedin.com/in/robertelles/> Kuelap GmbH - Geschäftsführer: Craig Chelius | Registergericht: Amtsgericht Charlottenburg (Berlin) | HBR 201125 B On Mon, May 10, 2021 at 12:20 PM Manoj VM <[email protected]> wrote: > Dear Robert, > > Thanks a lot for your help > > First we were trying with an existing group Id in @Permitable annotation, > after your suggestions we tried creating new group ids for our new > endpoints. > > Now, the new group Ids are populated in isis_permitable_groups table in > Cassandra. Yet we are not getting them in the permission list for > administrator(operator). Also the new end points are not present in the JWT > token created while logingin as administrator (operator). > > Could you please tell us how to assain these permissions to the role? > > I have a feel that we are in right direction, but still miles to go. > > Thanks, > Manoj > > On Mon, 10 May, 2021, 14:10 Robert Elles, <[email protected]> wrote: > >> Hello Avik, >> >> the gradle task publishApiToMavenLocal if for publishing the api artefact >> of the current projekt to the local maven repository but does not relate to >> permissions. >> >> In your cassandra instance you can also check the isis_permittable_groups >> table. If you see your new endpoints under the permittable group id then >> you know that the assign application worked. In the @Permittable did you >> set a new group id or did you use an existing one? With a new one you also >> need to assign the new permission to the user's role with whom you call the >> endpoint. With an existing group id there might be still a bug that you >> can not create new endpoints under an existing permittable group id. >> >> Best regards, >> Robert >> >> On Sat, May 8, 2021 at 8:40 AM Avik Ganguly <[email protected]> wrote: >> >>> Hi Robert, Community, >>> >>> Description : The APIs auto register only on a completely fresh new >>> database. >>> >>> Thank you for the quick response on this issue. >>> >>> I suspect the issue you see is due to permissions not updated. After you >>>> add a new API endpoint to a micro service you need to call the assign >>>> application endpoint of provisioner so that the auth-system is made aware >>>> of the new endpoint. Your rest controller endpoints must be annotated with >>>> @Permittable with the proper parameters. >>> >>> >>> The end points we have created are already annotated with @Permittable, >>> however we tried changing the group name to test whether the new group >>> name will force the permission creation, but it doesn't. >>> >>> And yes, every time we deploy a new end point, we call the provisioner >>> Assign api , which runs migration scripts, but doesn't add new permissions. >>> >>> What can we be missing out on? >>> >>> Perhaps there is a need for one more API in the initial API collection >>> which does permission creation, as we could see APIs in identity service >>> for creating permissions. >>> Also we found a gradle task for publishApiToMavenLocal, but running the >>> task did not change anything. >>> >>> With best regards, >>> Avik. >>> >>> Disclaimer: >>> >>> Privileged & confidential information is contained in this message >>> (including all attachments). If you are not an intended recipient of this >>> message, please destroy this message immediately and kindly notify >>> the sender by reply e-mail. Any unauthorised use or dissemination of >>> this message in any manner whatsoever, in whole or in part, is strictly >>> prohibited. This e-mail, including all attachments hereto, (i) is for >>> discussion purposes only and shall not be deemed or construed to be a >>> professional opinion unless expressly stated otherwise, and (ii) is not >>> intended, written or sent to be used, and cannot and shall not be used, for >>> any unlawful purpose. This communication, including any attachments, may >>> not be free of viruses, interceptions or interference, and may not be >>> compatible with your systems. You should carry out your own virus checks >>> before opening any attachment to this e-mail. The sender of this e-mail and >>> *Fynarfin Tech Private Limited* shall not be liable for any damage that >>> you may sustain as a result of viruses, incompleteness of this message, a >>> delay in receipt of this message or computer problems experienced. >>> >> > Disclaimer: > > Privileged & confidential information is contained in this message > (including all attachments). If you are not an intended recipient of this > message, please destroy this message immediately and kindly notify > the sender by reply e-mail. Any unauthorised use or dissemination of this > message in any manner whatsoever, in whole or in part, is strictly > prohibited. This e-mail, including all attachments hereto, (i) is for > discussion purposes only and shall not be deemed or construed to be a > professional opinion unless expressly stated otherwise, and (ii) is not > intended, written or sent to be used, and cannot and shall not be used, for > any unlawful purpose. This communication, including any attachments, may > not be free of viruses, interceptions or interference, and may not be > compatible with your systems. You should carry out your own virus checks > before opening any attachment to this e-mail. The sender of this e-mail and > *Fynarfin Tech Private Limited* shall not be liable for any damage that > you may sustain as a result of viruses, incompleteness of this message, a > delay in receipt of this message or computer problems experienced. >
