White-Labeling
Blue View Imaging can present itself under an organization's own name, logo, and color scheme instead of the stock Blue View branding. This lets one Blue View Imaging install serve an organization under its own identity without forking the product. Every setting below is optional, and the feature is entirely off — the UI shows standard Blue View Imaging branding, unchanged — until an administrator sets the first one.
Where to configure it
Go to FOG Configuration → FOG Settings, and open the BlueView Branding panel. It contains six settings, all empty by default.
The six settings
Organization name. The full name to display throughout the UI in place of "Blue View Imaging" — for example, a school district or company name. Setting this is what turns white-labeling on: every other branding element falls back to the stock Blue View mark and name until this one is set.
Abbreviation. A short form of the name above, used anywhere the full name would not fit — for example, in the compact navigation bar, which has limited width. Leave empty if you have not set an organization name.
Logo. An image to display in place of the Blue View mark. Uploaded through the panel itself; see below for what it accepts.
Primary color. The organization's primary brand color, entered as a 6-digit hex code including the leading # (for example #990033). Applied as a CSS custom property that overrides the default Blue View color scheme.
Accent color. A secondary accent color, entered the same way as the primary color.
Attribution line. The vendor credit line shown in the page footer once an organization name is set — for example, "Powered by Blue View Imaging". This only appears when white-labeling is active; an unbranded install has nothing to attribute, so it never shows this line. If left empty while an organization name is set, it defaults to "Powered by Blue View Imaging" automatically.
Uploading a logo
The Logo field on the branding panel is a file upload. Browse to an image, save the panel, and the file is stored on the server while the setting records its filename.
Uploads accept png, jpg and jpeg, at most 512×512 pixels and at most 512 KB. The mark renders at 22–35 pixels, so 512 is generous headroom for high-DPI displays; the limits are there to stop a banner-sized image or an oversized canvas being uploaded as a logo.
SVG is deliberately refused on upload, even though the rendering code will display one perfectly well. An SVG is XML and can carry script. A browser suppresses that script when the file is loaded through an <img> tag, which is all the branding code ever does — but the file is stored in the web root and served from the same origin as the administration interface, so anyone who opened it directly, or embedded it in an <object> or <iframe>, would run that script in an administrator's origin.
Placing an SVG on the server directly still works and is the supported route for one. That path already requires shell access to the machine, which is a far smaller and more trusted group than everyone who can reach a form in the web UI. Lowering that bar to a browser upload without an XML sanitizer would be a poor trade.
However the file arrives, the branding code validates the stored filename before it is used. A value containing a slash, a backslash or a colon, or beginning with a dot, is rejected, as is any extension outside png, jpg, jpeg and svg. A setting reading ../../evil.png resolves to nothing rather than reaching outside the directory it is meant to.
No configuration, no change
If Organization name is left empty, none of this applies: the navigation bar, login page, page titles, and footer all show the standard Blue View Imaging mark and name exactly as they do on an install that has never touched these settings, and no attribution line appears. White-labeling is additive — turning it on requires deliberately setting a name, and there is no partial or accidental state where some branding is overridden and some is not.