Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Administrator privileges required for OOo installation | ||
---|---|---|---|
Product: | Installation | Reporter: | wiep <piotrwie> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | CLOSED NOT_AN_OOO_ISSUE | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | etnoy, issues, jdavid.eisenberg, piotrwie, rainerbielefeld_ooo_qa, soloturn |
Version: | 680m77 | Keywords: | oooqa |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows, all | ||
Issue Type: | FEATURE | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
wiep
2005-02-14 17:13:55 UTC
should be: installation for one user only (even if it is connected with limited components registration etc... - rarely used, but for which administrator is needed) reassigned reassigned I am hooked up on a non-admin account on my school and the OOo 1.1.4 and 1.1.0 installs work just fine. Now I wanted to test the 1.9 beta versions, downloaded 75 MB of data just to get the message that I must be administrator to install the software. I really dislike this kind of behaviour and just locking out the user. At most, it could display a very visible warning that says that some features won't work unless installed by an admin, then it's up to the user to continue. I see this as quite important for OOo, and would like someone to close this bug pronto. This is not a bug! OOo 2.x needs admin rights to install. Works as designed. AFAICS this won't be changed in the near future. If it is not planned to be changed, please provide non admin users a special installer - to make a single desktop installation possible. I hate idea of being forced to recompile everything only to install the software on my desk at work! I think administrator priviledges are required only for "install for all users" option. It is not fair, because in other OS you needn't be administrator - you can install it always in your own /home/xxx/directory. I agree with the above poster, an option to force installation no matter what is needed. Tell me, what breaks when you install as non-admin? Could the installer generate a big fat warning? *** Issue 42768 has been confirmed by votes. *** the issue is that administrator priviliges are required, and it should not be the case. any user should be able to install it. I am curious as to the comment on 7 March: "This is not a bug! OOo 2.x needs admin rights to install." The word "needs" is key here. Some specifics of what things would not be possible with a normal user install would help us understand the issue better. This issue really is an obstacle for evangelizing OOo. You want to be able to hand someone a disc and say, "Use OOo for a while; you'll love it." You don't want to have to ask, "Oh, by the way, do you have adminstrator privileges on your machine?" If requiring admin privileges is a matter of single user vs. all users install, then put that question as close to the beginning of the install process as possible. (Otherwise, you have the possibility of people getting 90% of the way through the install and then finding out they need to be admins--a sure way to alienate potential customers.) Yes, this "bug" as I call it can give serious problems later on. About a year ago was a problem with OSS software and admin-requirements on win32, and when I saw OOo take this turn too I felt very disappointed. Admin requirements are never good, and it must be some way to at least try instead of the "nope, I don't want to continue because.." attitude the current installer has. Also, there should be an option to install either systemwide or only for the current user. The "This is not a bug!" comment was made because "of" mistakenly thought that The "This is not a bug!" comment was made because "of" user mistakenly thought that the spec did not require the installation to provide non-admin installation. Look at the Windows Installer GUI Spec on http://specs.openoffice.org/installation/index.html In Section 6.8 it describes supporting admin and non-admin installation, for example saying that if a non-admin tries to perform an all-users installation then the installation program should only support the single-users installation. So from the spec point of view, this is clearly a bug. It is also a "bug" from a product-design point of view. Windows does not permit non-administrators to install fonts, but otherwise the rest of OpenOffice does nothing for which Windows requires admin privileges. This means that the installation program could have (and should have) been written to check admin rights and then install everything but the fonts for non-administrators. *** Issue 53766 has been marked as a duplicate of this issue. *** *** Issue 46143 has been marked as a duplicate of this issue. *** I repeat, this is a bug and it should be fixed. I do not know if it is a bug, but it is really not a nice feature in my case :-( This is the same situation for unixes (solaris and linux in my case). In our software development department (about 300 peoples), all our software tools are installed in a specific networked shared home (/home/tools) and are owned by a specific user (toolsmgr). With the native installers of OpenOffice.org 2.0, it is nearly impossible to install it in this conditions. The install_solaris.sh script (downloaded from the developpers resources) allowed me to succeed on this platform, but I can not install openOffice.org 2.0 on our Linux RedHat EL4 machines because rpm can not be executed in install mode without root privileges... Currently, the only option I see to keep our tools homogeneous for every platforms is to keep OpenOffice.org 1.1... You should probably not define or limit the deployment model of OpenOffice.org in place of the users : some are using it on their own box, others rely on an external administrator, others split up the administrative responsabilities between teams, etc. It is probably better to let people like BlastWave, Ubuntu, Debian, RedHat, etc. doing this packaging job : it is their reason to be. Martin: this is causing rather a lot of grief. Would you be able to tell us the status of this? No changes about this yet. *** Issue 73600 has been marked as a duplicate of this issue. *** Someone told me : "Use setup with parameter /a. You'll get an installation without admin priviliges but without systemintegration". Didn't tried it yet. It would be better to have a combobox or a checkbox when the installation start to let the user choose. If admin rights are needed to install parts of OO, this should be done using elevated priviliges. That way also non-admin users can install OO. setup /a means "administrative install", but unfortunately it checks the same privileges - and i guess this one is a real bug. but in general, it would be very nice if installing openoffice works like all the other medium decent installers which let you choose between "install for all users" (which needs sometimes admin privileges), and "install for this users" (which never needs admin privileges). *** Issue 91649 has been marked as a duplicate of this issue. *** Hi, people would like probably to try ooo in my organisation, but the motived people would like to show a bit that it works, before starting asking autorization to the Administration services. The potential are about 10.000 users... For this reason, this would be crucial to be able to install ooo as simple user, as we do on our machines with many other programs. Could it here be possible, in simple words for managers that are still IT-iliterate, to have the list of the reasons for which an admin access is necessary? And how to install it without? Thanks in advance for your help. bib_bxl: I have gotten around the problem by using OpenOffice.org portable; you don't need to be admin to install it (at least I didn't the last time I tried), and you can install it to hard disk just as well as to a flash drive. http://portableapps.com/apps/office/openoffice_portable Thanks jdeisenberg: this worked. This is a solution that should be mentioned, specially for corporate targets. I hope anyway that there will be an answer on the very question we formulated from the persons that have a competence to do it, so we can go on with this issue. All the best. Thanks jdeisenberg: this worked. This is a solution that should be mentioned, specially for corporate targets. I hope anyway that there will be an answer on the very question we formulated from the persons that have a competence to do it, so we can go on with this issue. All the best. Not a bug, works as designed, workaround for not-admin-users exists, so NOT_AN_ISSUE. |