Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] RE: UI customizations ( best practice / current design? )

Subject: Grouper Developers Forum

List archive

[grouper-dev] RE: UI customizations ( best practice / current design? )

Chronological Thread 
  • From: "Black, Carey M." <>
  • To: "Hyzer, Chris" <>, "" <>
  • Subject: [grouper-dev] RE: UI customizations ( best practice / current design? )
  • Date: Tue, 27 Jun 2017 18:25:52 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is;; dkim=none (message not signed) header.d=none;; dmarc=pass action=none;
  • Ironport-phdr: 9a23:uimvFRyvN8oSXEjXCy+O+j09IxM/srCxBDY+r6Qd0ekQIJqq85mqBkHD//Il1AaPBtqLra8cw8Pt8IneGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2NBXupSj4zS8AFw+7fSF1POXuUMaGis+3xvK/4bXSeA4OmSKwZ7U0IRmr+0GZ/MYMhpZ6J7x0xhbXinpOZ+lMw250fxSekwu2rpO/5pl+6ylK/v4s6eZBV7n3ZaI1UeYeATg7ZTMb/sru4FPpSQKE5T9UeWwMnwsAJk6PpEXwWp76sW2j7LFV3zKHe8D6UOZnCnyZ8653RUqw2288PDkj/TSPhw==
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

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

Refs that I have reviewed: (
dated to prior to v 2.2 ) ( looks
more relevant, but does not really address customizing.. more of an overview.) (
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/ */
} else {
/** use the default file */

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
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?


-----Original Message-----

On Behalf Of Black, Carey M.
Sent: Monday, June 26, 2017 5:18 PM

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
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
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
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

Archive powered by MHonArc 2.6.19.

Top of Page