Hello Vyacheslav

> On Sep 14, 2016, at 9:55 AM, Vyacheslav Vakhlyuev <[email protected]> 
> wrote:
> 
> I mapped core's groupmgr.assignRole method to existing endpoint in adminmgr
> (assignUser endpoint) because the entity we use there (UserRole) is the
> same for Group and User objects. The only difference is "isGroupRole"
> boolean field in this entity. Definitely, for conformity's sake, I can use
> a separate endpoint for this. Do you think we should introduce an
> additional endpoint(s) for assign/deassign group role?

Yes.  Sorry, that I wasn’t clear on this before.  We should map the new admin 
and review functions (assign/deassign/groupRoles, roleGroups) that were added 
to the GroupMgr to a new endpoint in enmasse.  This new endpoint will 
eventually have all of the groupMgr functions. I can help you with this part as 
it’s a bit of scope creep.  What I mean is you can add the new ‘services’ that 
are associated with your new methods in groupmgr.  I’ll add the preexisting 
services after your work is complete.

Will that work for you?

> 
> On Sep 14, 2016, at 9:55 AM, Vyacheslav Vakhlyuev <[email protected]> 
> wrote:
> 
> Regarding accessMgr.createGroupSession. Did you mean core's accessMgr or
> enmasse one?
> In enmasse I introduced an additional endpoint for clarity. The same is
> true for core's accessMgr, by using a separate (not overloaded) method I
> wanted to underline that the session is being created for Group and it's
> trusted.
> Do you think we should rename core method to use Group as argument and
> become overloaded?

The core.  I’d add a method that looks like this:
    @Override
    public Session createSession(Group group)
        throws SecurityException

which will then map to enmasse service similar to how you already have it 
defined:
    /**
     * {@inheritDoc}
     */
    @POST
    @Path("/" + HttpIds.RBAC_CREATE_GROUP + "/")
    @RolesAllowed({SUPER_USER, ACCESS_MGR_USER})
    @Override
    public FortResponse createGroupSession( FortRequest request )
    {
        return accessMgrImpl.createGroupSession( request );
    }


No need for isTrusted flag because groups won’t ever be associated with a 
password meaning it’s always trusted.

Thanks,
Shawn

Reply via email to