Grouper Developers Forum

[Emily Eisbruch <>]

HI Chris and Carey,

Perhaps  it would be helpful to add more explicit info at the top of this page regarding how we expect customizing of the Grouper UI to be handled moving forward? 

https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI

This could help address this issue Carey raised on this page (see in the box with yellow shading)

https://spaces.internet2.edu/display/Grouper/Grouper+Wiki+Issues

Thanks

Emily

Emily Eisbruch, Work Group Lead, Trust and Identity
Internet2

office: +1-734-352-4996 | mobile +1-734-730-5749

---

From: <> on behalf of Hyzer, Chris <>
Sent: Tuesday, June 27, 2017 3:20 PM
To: Black, Carey M.;
Subject: [grouper-dev] RE: UI customizations ( best practice / current design? )

 

Yes, the more includes we have or pluggable views the more easily patched.   The old admin UI did that and it was a mess to figure out, so we need to make it straightforward too.  I think contributing customizations as options and making things generic is the way to go :)   i.e. your customization could be a patch that defaults to not affect others if that is the desire :)

Thanks
Chris

-----Original Message-----
From: Black, Carey M. []
Sent: Tuesday, June 27, 2017 2:26 PM
To: Hyzer, Chris <>;
Subject: RE: UI customizations ( best practice / current design? )

RE: " If you customize a file, and you try to apply a patch, it will fail and let you know. "
        Oh. Good to know. I had not found that in the docs that I have read so far.
        So far my customizations have been limited to config files. Before I went farther I wanted to understand the designed approach for UI customization.


        Refs that I have reviewed:
        https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI  ( dated to prior to v 2.2 )
        https://spaces.internet2.edu/display/Grouper/Grouper+new+UI ( looks more relevant, but does not really address customizing.. more of an overview.)
        https://spaces.internet2.edu/display/Grouper/Grouper+UI+Properties ( Ok.. promising, but I am not sure this is still the "right way" for v2.3.)



RE: " Then you can merge it in or whatever.  Does that address it?"
        It is something. But I don't think it is ideal.
        Where does the "new/changed" files land on disk? When there is a conflict detected?

        I was hoping more for a process like the config overlay only for the UI elements.

        Generally something like:
        /** or a config file to point to the local files instead of searched directories all the time. */
        /** Or at runtime by default use .../local/<file> instead of ../standard/<file> */
        If (.../local/some.jsp ) {
                /** use the file out of .../local/  */
                .../local/some.jsp
        } else {
                /** use the default file */
                 ../standard/some.jsp
        }

               
        I think such a model might allow for replacement/extension and allow the "uprgrade" to more simply blindly replace the delivered UI without concern of stomping on customizations.
                The installer/upgrade could still issue "warnings" about customizations that exist and should be validated.
        It still requires the customizations to be validated after the upgrade and "corrected/merged" as system level changes might have added/changed/broken things too.
        However, in that case the Users could choose to "suppress the customizations" ( rename to different name) then fix and restore to original name.
        And it provides an "obvious" diff of what they created in ".../local/" vs ".../standard/".

--
Carey Matthew

-----Original Message-----
From: Hyzer, Chris []
Sent: Tuesday, June 27, 2017 11:32 AM
To: Black, Carey M. <>;
Subject: RE: UI customizations ( best practice / current design? )

If you customize a file, and you try to apply a patch, it will fail and let you know.  Then you can merge it in or whatever.  Does that address it?

Thanks
Chris

-----Original Message-----
From: [] On Behalf Of Black, Carey M.
Sent: Monday, June 26, 2017 5:18 PM
To:
Subject: [grouper-dev] UI customizations ( best practice / current design? )

I am looking for a general overview for "How to best customize the Grouper UI (new)" so that you don't paint yourself into a corner for the next upgrade/patch.
        I know that the "upgrade" condition is a bit of a crystal ball type question, but is there a plan for how someone can at least survive an "patch" process without losing customizations?

Is there any guidelines or advice on the general topic?


Specifically , I am ok with using some of the localization tools to "adjust text". But there are some more structural things that I would love to move around too.
        Example: I want to move at least some (if not all) of the "Loader" functions from the "grouperLoaderViewMoreActionsButton" up to the "groupViewMoreActionsButton".
                   I think I would ideally want to see a "sub section" on the "groupViewMoreActionsButton" that would be the full list of items on the "grouperLoaderViewMoreActionsButton". ( Plus the "Run Loader Diagnostics" button function too.)
                        And the "sub section" would be guarded by the same permissions as the "Loader jobs". ( So not every user would see the sub-section.)
                  I find the separation of these functions into different buttons almost as "jarring" as switching between the New UI and the Lite UI/Admin UI.


--
Carey Matthew