Closed Bug 103545 Opened 23 years ago Closed 11 years ago

Standard config for enterprises needed

Categories

(Core :: Preferences: Backend, enhancement)

Product:
Core
Component:
Preferences: Backend
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: Michael.Kolmodin, Assigned: Michael.Kolmodin)

References

Details

Enterprises and ISP:s needs a way to "preset" certain user preferences
such as
   * Mail-accounts
   * News-accounts
   * Proxies
   * Startpage
   * Publisher (once the upload feature is implemented in Composer)
   * Throbber?
   * LDAP Address Book

Preferarably, the user should get these without any intervention or,
possibly, with an easy one. The function should work both in the ISP scenario
where the ISP "hints" their users about relevant settings but also in the
enterprise wher the IT dept has a need to easily config moz in a standardised
way.
Michael, thanks for ccing me.

This bug is critical for acceptance of Mozilla by ISPs.

There are actually several ways to achieve most of what you request. You can
adjust the default prefs in <instdir>/default/prefs/. For Mail (/News?)
accounts, you can add isp files, see Netscape 6. (If you need commcercial help
with any of that, feel free to contact me privately.)

However, there are some important questions, e.g.:
- Should all this happen completely automatically? E.g. the ISP knows the
  username etc. and wants to completely configure Mozilla without any user
  interaction.
- In the ISP scenario, what if Mozilla is already installed? The ISP's settings
  should not override the user's ones. Compare bug 43429.

This might be a tracking bug or too broad. CONFIRMing in the meantime.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Would this not be served with a package or packages that change all.js and the
like?  There seems to be no need to change the user prefs....
Hm... As I see it, there are a number of ways to achieve what we want:

  1)An  ability for i. e, an ISP to "tweak" a distribution according to their
    needs before it's distributed to the end user. From Ben's explanation, I 
    understand that this is at least partly solved already.

  2)An ability for a user to somehow say "give me all the settings relevant
    for my ISP or company", i. e. by visiting an URI after having installed a
    standard version of Moz.

  3)The ability for a ISP/IT dept to somehow "push" settings on a user after
    installation of Moz.

1) is fairly limited - in real world people tend to download moz from a 
different places (and in different versions!). If 2) gets implemented, 3)
might be implemented in a number of ways without direct support in Moz.

There is also a distinction between settings which just *adds* things to the
configuration versus settings which  there are really only one of. From a user 
perspective, if someone just adds a new news server, mail server, address
book etc it's not really a big deal and could handled by an "implicit"
agreement like "Yes, it's OK that my ISP updates mail servers etc.."
Basically, it just makes it easier to access certain things. 

To really  change the behaviour, i. e. by changing startpage or proxies
definitely needs user attention in an explicit way. Looking at the list so 
far, it looks like we don't really need this (besides what's already possible
through method 1) ). Or?

The problems related to 2) are more related to policy. One way to handle it
might be to say that the ISP can just add entities (mail servers, address 
books...) or change those which already has been added by the ISP. That is, 
certain entities in the config "belongs" to the ISP.
Oops, yet another one:

- An ability for the user to say "Give me all the relevant settings for my ISP"
  *during installation* when installing a standard moz. In this case, the ISP
  should be able to make any kind of configuration, possibly based on i. e.
  username, password... (sorry Ben, it took some time for my little brain to
  grasp what you said ;-) 
  
Macro, as it happens to be, a confirmation (rather, an explicit action) of the
user for adding a new Mailnews account is possible, and maybe currently even
required, while having a confirmation for changing proxies and startpage is
currently not possible unless you implement it in your own code.
That might be something which should be changed, and maybe we shoulod file a
blocking bug about just that.

As for your options, 2 is somewhat possible by you creating an XPI (a Mozilla
software installation package), which just overwrites the default prefs etc.
i.e. changes a normal Mozilla / Netscape 6 into a customized one.
(That XPI can run an install script in JS; but IIRC, that JS unfortunately
cannot pop up UI for technical reasons, so it will be hard to implement that
confirmation for overwriting proxies there. However, the user will have to
confirm the installation of the (whole) XPI anyway.)

> ISP can just add entities

Well, "adding" a proxy is also a major alteration of prefs.

> - An ability for the user to say "Give me all the relevant settings for
>   my ISP" *during installation* when installing a standard moz.

You mean in the Mozilla installer? Note that the user doesn't have to use it -
you can just extract a zip.
QA Contact: sairuh → rvelasco
AOL/Netscape provides product offering. Removing AOL/Netscape employees on this 
RFE due to conflict of interest. Reassigning to reporter.
Assignee: bnesse → Michael.Kolmodin
QA Contact: rvelasco
I'm interested in enterprise deployment and configuration enhancements - I have
a question about the last comment:

==================================================
------- Additional Comment #6 From Jeff Hooker 2001-10-13 00:46 -------

AOL/Netscape provides product offering. Removing AOL/Netscape employees on this 
RFE due to conflict of interest. Reassigning to reporter.
==================================================
What is the practical implication for a requested feature if it presents a
conflict of interest with AOL/Netscape?  
There is no conflict of interest, Hooker wrongly thought so (he's probaböy new).
Otherwise, there would be no difference between Netscape 6 and AOL client
software. Obviously, Netscape is also intended to be used by other ISP and will
be doomed, if it isn't.

As to your question, the direct consequence, if there is really a conflict of
interest, is that Netscape employees probably won't work on it. (In other cases,
they did nevertheless.)
Adding Douglas, who filed bug 166946, to the cc list.
One area IE really has an advantage at the moment is the ease with which it can
be customised through the use of Group Policies. For example, at one of our
clients we run two proxies -- one that general users use, which is configured to
block various sites (eg. hotmail), and another that allows unrestricted access
for administrative staff.

I'm not sure how a similar kind of setup could be achieved with Netscape/Moz, as
it stays clear of the Windows registry (and other non-portable mechanisms) of
specifying settings (at least from what I have seen). I'd love to be able to
start recommending a Gecko-based solution in place of IE6!
We need the ability to set a variety of mail, news and directory preferences
based on the user's mail domain.  I'm sure we're not alone: this is something
enterprise providers typically need to meet various security and functional
(e.g., directory servers with different search bases; mail servers serving
different domains have different capabilities) requirements.

In the past (Netscape Communicator 4.[78]), this was easy to do by writing the
appropriate JavaScript code and deploying it as a Netscape.CFG file.  It strikes
me that Mozilla's ability to manage multiple mail accounts would make this type
of code more cumbersome -- assuming some clear documentation was available on
how to do this sort of thing (we haven't found it yet) -- so perhaps it would be
appropriate to have some built-in that tested for the mail domain of the current
user.  Conditional code to Do What Needs To Be Done could then be written
without regard to *which* particular account was active at run time.

Again, this is a big deal for us, and I suspect other enterprise providers who
want to stick with Netscape/Mozilla but need to migrate from the 4.X versions.
*** Bug 136492 has been marked as a duplicate of this bug. ***
I'm the originator of bug 136492 and I'm not entirely happy about 'my' bug being
dupe'd to this one.  Yes, this one is older (by a couple of months) but mine has
more notes, has more *recent* activity, has 2 blockers associated with it, AND
has a lot more votes (16 vs 3).  I suspect that part of this is from the
keywords I chose for the title, i.e., centralized corporate policies.  So, is it
really more efficient to dupe it to this bug (which hasn't been touched in 2.5
years)?

It's a shame this wasn't caught earlier, really, since both bugs now have good
discussion.  Assuming that *someone* is actually working on these issues, then I
would defer to their judgement about which bug to keep.  And if my bug continues
to be dupe'd, I would try to: summarize it's notes and repost them here; urge
'my' 16 votes to revote for this bug.  But I'm not going to do any of that until
I get some feedback...
Tony Tovar, I checked out the duped bug and disagree that there's much important
information (more than here), nor any activity to mention. Confirming dup.
transferring blocker bug 147344 (breakup profile to support roaming) from dupe'd
bug 136492
Depends on: 147344
Since the bug 136492 was dupe'd to this one, and it had been 'confirmed', does
that mean that *this* bug should be confirmed?

Also, can we consider renaming this bug?  I think there needs to be mention of
the keywords "central corporate policies" so that more people can find this.

Finally, I've copied below all the relevant commentary from 136492.
__________

Has there been any progress on the Client Customization Kit?  
http://www.mozilla.org/projects/cck/
The page has been updated since I last checked (2002) and the old Netscape
version is now gone.  Instead, it talks about a prospective new CCK for Mozilla
but I don't see any mention of actual code.  hmm, the 'Historical Background'
link says it was last updated on Jan 1, 2005, but it's VERY historical, i.e.,
there's no mention of any current Mozilla sw.
__________

Once again, just for reference, here are some links re the market for config
tools like CCK and IEAK:
http://www.microsoft.com/windows/ieak/default.mspx
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2860153,00.html
__________

References to a possible RFC we could/should implement:
  Application Configuration Access Protocol (ACAP)
  http://www.ietf.org/rfc/rfc2244.txt
__________

- 2003 Slashdot discussion of corporate implementation of Mozilla,
  http://ask.slashdot.org/askslashdot/03/01/19/2239259.shtml
- one admin's notes for corporate-izing Mozilla
  http://www.alain.knaff.lu/howto/MozillaCustomization/
- current NS version of CCK
  http://channels.netscape.com/ns/browsers/partners/cck.jsp
- Documentation for NS7 version of CCK
  http://home.netscape.com/eng/mozilla/ns7/CCKDocs/pdf/cck_guide.pdf
___________

One of the posts asked about creating a centralized *personal* config.  The idea
being that you could maintain a personalized profile (bookmarks?) on a central
location and use it wherever you went.  So, if we create a formal 'central'
profile manager, he would like there to be an option to pull it from an
internet-connected home PC and with a password check.
___________

This Mozillazine discussion says that settings in 'user.js' take precedence over
settings in 'prefs.js' (which is what the GUI interface 'about:config' edits). 
Relevant?
http://www.mozillazine.org/talkback.html?article=2839


I don't think splitting profiles is necessary to implement what's requested here
at all.

This bug is not about central policies either, but about presets. The difference
is that the user can change the latter. We do have contral policies for prefs.
That includes most of the things you asked for, incl.
> - the default homepage is always our Intranet server
> - HTTP access is always via our proxy-forwarding server
> - ActiveX scripts marked as "safe" are *not* run automatically
I don't know what specifically you're requesting. Maybe what you want is indeed
a different bug, but the old one wasn't clear. Don't say "something like", but
very specific things that you want to configure which you can't configure right now.

Basically, this bug is about making life easier for users by defaulting to the
right settings when you or they install Mozilla. If you are asking to *force*
certain settings on a user, file a new bug about *specific* things to force on them.
No longer depends on: 147344
Old Netscape (and to a lesser degree) new Netscape developed and supported two
utilities they called their Custom Configuration Kit and Mission Control
Desktop. The first allowed corporate IT folks to customize the generic Mozilla
suite release packages to their own particular needs. The second allowed them to
manage key preference (pop-up exception sites, SSL versions and encryption
algorithms, proxy servers, etc.) settings from a local web server. Unfortunately
for those of us interested in promoting Mozilla in corporate enterprises, the
Mozilla Foundation has not shown much interest in (1) bringing those two
products up to date, and (2) making them available to corporate users on a
maintained/licensing basis. Until I hear MF announce CCK and MCD support for
Firefox, I will continue to advise my corporate clients not to adopt it because
it is simply not supportable in large (>1,000 seats) enterprises.
It sounds like 'standard' is being used as a synonym for 'initial' here, and
that 'enterprise' is being used unnecessarily (since ISPs, retailers, etc also
have an interest in configuring initial settings).

Clearly, initials presets are different than 'live' configuration policies.  So,
if this bug is only about initial presets, then I think bug 136492 needs to be
un-dupe'd from it.  If this is, in fact, what is ultimately done, then I
apologize for all the unnecessary comments I've added to this bug (but, then, it
wasn't my idea to dupe the two together)
xref: bug #267888 Group Policy in Windows can solve some problems, yes is
debatable how to implement one-platform feature.
FYI
There is a new v0.2 alpha of the Client Customization Kit (CCK),
http://www.mozillazine.org/talkback.html?article=7168
http://www.mozilla.org/projects/cck/firefox/

It is designed to work with the next release of Firefox (v1.5 aka "Deer 
Park").  It's an add-in that allows you to generate an .XPI file of your 
current settings, then bundle that .XPI with the installer.  I think the add-in 
works with the current v1.0.x of Firefox but only the Deer Park installer will 
recognize the .XPI.
QA Contact: preferences-backend
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.