Grouper Developers Forum

["Hyzer, Chris" <>]

Heres an example that works in 2.3 or 2.4...

https://spaces.at.internet2.edu/display/Grouper/Grouper+hook+which+adds+link+to+UI


-----Original Message-----
From: Hyzer, Chris 
Sent: Wednesday, March 13, 2019 8:30 PM
To: 'Black, Carey M.' <>
Cc: 
Subject: RE: [grouper-dev] Hooks and the UI....

Sure, lets work together to get something working... any chance you can 
upgrade?  Should not be difficult if you are 2.3 fully patched... 😊

-----Original Message-----
From: Black, Carey M. <> 
Sent: Wednesday, March 13, 2019 4:06 PM
To: Hyzer, Chris <>
Cc: 
Subject: RE: [grouper-dev] Hooks and the UI....

Chris,

While I did not get into this detail, I was planning on the hook paying 
attention to the context and only trying to "redirect" the events sent from 
the UI. ( Doing such a thing from a WebService or GSH call clearly would not 
make sense. )
        My ref: " The hooks context (still needs to be completed), holds 
information such as the current user, the current environment (UI vs WS etc), 
threadlocal data (e.g. the current http request), etc. "

RE: " I think the API hooks should have little UI code in them "
        Understood, and I agree in principle.
        However, it feels like that is the only hammer I have right now.


Unfortunately  I want something fairly quickly. (maybe a few months with v 
2.3 fully patched ) 
        So I am willing to be a bit "hacky" about it. :^( I just don't want 
to overlook a "non-conflicting" or "standard" way to go about it if it exists.


Maybe the "better idea" is to just start with a "custom JSP" and "bolt it on" 
to the UI.
        That should insolate this work from the v2.4 upgrade and Grouper 
patch process.
        If I really needed to I could even add a new servlet class (but that 
would require WEB-INF changes that could conflict...)
        
        Or more directly... could the "Grouper gods" maybe give me a formula 
about how to make a "not guaranteed to continue to work in the future" plan:
        Something like:
                clone this class and modify as "desired" ( compile to a jar 
that you put it in WEB-INF/lib )
                add a jsp/html file(s) here
                ( if needed ) modify WEB-INF/web.xml "something like this"
                Find a way to get a link to the user(s)
                        I could live with a link in the header/footer to get 
them started....

I can live with the following till there is a better designed model. (and 
maybe this "plan" will spur that design into reality? )
        Model is "remove it all modifications", patch, then put "the 
modifications back" (at your own risk).
 
-- 
Carey Matthew 

-----Original Message-----
From: Hyzer, Chris <> 
Sent: Wednesday, March 13, 2019 11:46 AM
To: Black, Carey M. <>; Gettes, Michael <>
Cc: 
Subject: RE: [grouper-dev] Hooks and the UI....

I think you could write a hook that adds attributes.  Maybe we need a new 
UI-hook that then could (based on something you stuff in the httprequest 
object?) redirect the user to another page... I think the API hooks should 
have little UI code in them, and it should be failsafe so it will still work 
outside of a UI context... ok?  Whats your timeframe and version of grouper?  
If not 2.4 fully patched can you upgrade to that?

Note this is a little complicated since Grouper doesn’t go to screens but 
rather does ajaxy things, but we can discuss the particulars and make it 
happen...

Thanks
Chris

-----Original Message-----
From:  <> 
On Behalf Of Black, Carey M.
Sent: Wednesday, March 13, 2019 11:18 AM
To: Gettes, Michael <>
Cc: 
Subject: RE: [grouper-dev] Hooks and the UI....

Michael,

To be fair... I did ( for a second ) consider sending the user an email with 
the link I want them to go to. 
        But that seemed so silly that I dismissed the idea. They are already 
in the app. Why should they need to "go check their mail" to get to the right 
screen?


I don't yet have any idea what work is being done for "workflows" or 
"approvals" in Grouper. And I am not sure if they would be applicable for my 
needs. 
        However, maybe a workflow that could be "kicked off" by a Membership 
add/remove/change? 
                If it could auto assign attributes to the Membership then 
that might remove my need for a custom hook all together. 
                I would also expect (guess) the "workflow" would be 
asynchronous with the UI event. So I would not expect it would also be able 
to direct the active user to a different URL as well.  ( Maybe it could, 
maybe it could not... all depends. )


And I might even be open to the idea of a "page that is all my own" too. ( I 
still have the work of getting the user to that page, but I think I can link 
users in to it. )
        But again... is there a design for grouper users to "add custom 
pages" to the UI?
                The page would likely need to let the user:
                         "pick a group", 
                        pick a subject ( at a minimum ) , 
                        maybe even 
                                provide a dynamic enough UI to "prompt the 
user for the attribute values" before the membership is created too. (or that 
would be moved to a "second custom page".

-- 
Carey Matthew 

-----Original Message-----
From: Gettes, Michael <> 
Sent: Tuesday, March 12, 2019 11:34 PM
To: Black, Carey M. <>
Cc: 
Subject: Re: [grouper-dev] Hooks and the UI....

I believe work has been going on with “workflow” and “approvals”.  I am 
particularly interested in the approvals.  Seems like what you want to do 
might be similar to that sort of processing - of course, I have zero idea of 
how workflow/approvals are being implemented.  Maybe it will save you a lot 
of time/effort?  Maybe not.

/mrg

> On Mar 12, 2019, at 11:24 PM, Black, Carey M. <> wrote:
> 
> All,
> 
> I have a desire to have a Hook "do work for the user" then "redirect them" 
> to a different UI page. But I am not sure how to go about it.
> 
> Specifically I am thinking this.
>       1) User adds a membership to a group.
>       2) Hook auto adds attributes assigned to the membership ( maybe in a 
> postCommit Membership hook) [ based on attrs on the group and elsewhere...] 
>       3) ( Take over the world. Er.... ) Send the user to a UI page where 
> the user would be able to add values to the attributes that were just 
> assigned to the membership.
>               Out of scope for this question... When all values are 
> supplied by a user, then a change log consumer would do some 
> "provisioning/deprovisioning" work to another system.
> 
> 
> Normally the user lands on a URL like : 
> /grouperUi/app/UiV2Main.index?operation=UiV2Group.viewGroup&groupId=<groupID>
>  after adding a membership to a group.
> I want them to land on this URL instead.
>       
> /grouperUi/app/UiV2Main.index?operation=UiV2MembershipAttributeAssignment.viewAttributeAssignments&groupId=<groupID>
>  
> &subjectId=<subject_ID_that_was_assigned_a_Membership>&sourceId=<subject_source_id>
> 
>       Which the user could navigate to in the UI by doing all of the 
> following:
>               ( Starting from the "normal" outcome.)
>               Click on the subject that is a member that was just added. ( 
> maybe after finding them in the list of memberships)
>                        
> -->/grouperUi/app/UiV2Main.index?operation=UiV2Subject.viewSubject&subjectId=<subject_ID_that_was_assigned_a_Membership>&sourceId=<subject_source_id>
>               Find the "Membership" that was just created in all of the 
> users Memberships
>               Click the "actions" menu button at the end of the row
>               Select the "Attribute Assignments" option.
>                       --> Get to the URL I want them at.
> 
> 
> I did read though the hooks docs ( again ) and I did see something that 
> might work ( maybe? ). 
>       RE: " Some of the built-in values for the attributes are: 
> HttpServletRequest, HttpServletResponse, HttpSession (Http classes for UI 
> and WS only). "
> 
>       So I have some access to the HttpServletResponse object, but....  is 
> it safe to call a "sendRedirect(URL) " during a Hook? ( I am thinking 
> postCommit after doing the rest of the "attribute work" for the hook.) 
>       Or is there a "designed way" to achieve my goals? ( Maybe a specific 
> "hook attribute" that I should set instead of calling sendRedirect myself? )
>               
> 
> Also... IF I whisk the user away to a different URL.... 
>       Will there be any issues with later Hooks that might still be waiting 
> to be processed? ( My hope is they will still all fire "as normal". If they 
> veto.....??? the Veto shows up on the redirected URL? ( or is just eaten 
> because of the redirect? )
> 
> 
> BTW: My second idea was to "fix" the action button on the group "member" UI 
> to have the "Attribute Assignments". ( Still the user would need to find 
> the person they just added. Not as useful as being auto routed there, but 
> that would likely be much less work for me and does not seem to be 
> unreasonable. Even better if the sort order was somehow set to "newest 
> members at the top" for the list. :)  )
>       So if you want to point me in the right direction to patch a 2.3 UI 
> that way, I would be open for that too.....
>       To be fair, I really want that button option anyways.... And I want 
> the hook to auto send the user there too. ( Yea.. I like to have my cake 
> and eat it too. )
> 
> Thanks in advance/clue bricks. :)
> 
> -- 
> Carey Matthew 
>