Issue 77257

Created attachment 45056 [details]
Screenshot example of simple File Association Management interface

When you install OOo on Windows you are usually doing this for all
users. Then the setup application registers the file associations for
all users. The file association manager in OOo will  not be able to
access these settings! Instead of this it will try to set something for
the current user. This will rather screw up things than fix them.

A file association manager in OOo could make sense as part of the setup
as then it could be run with admin rights. In fact the existing "repair"
functionality of the setup should do exactly that, of course some other
things also what might be unwanted.

Did you try "repair"? IMHO that should be enough.

A file association manager inside OOo does not make sense at all and especially
on Vista is a No-No.

Repair did not work...

There is absolutely no reason why OOo should not be able to manage these
associations after it is installed.

My problem apparently was caused by permissions problems on the registry
settings. My argument is, if these can be fixed manually, by changing the
permissions, there is no reason that an OOo FAM could not *also* handle
permissions problems - again - as long as the User had Full Admin Rights...

> When you install OOo on Windows you are usually
> doing this for all users. Then the setup application
> registers the file associations for all users.

Yes - all of which is exactly how the FAM would/should work...

> The file association manager in OOo will not be able to
> access these settings!

Eh? Why not? Oh - re-reading my original post, I didn't make it clear that this
functionality would only be available if the user trying to make use of it was
logged on with Admin Rights... this is obvious, so I didn't specifically mention
it...

> Instead of this it will try to set something for the current user.
> This will rather screw up things than fix them.

Not if they are logged on with Admin Rights - and again, there is no reason that
 OOo couldn't simply detect this, and display a message (that this functionality
requires being logged n as a User with Full Admin Rights) if a User who does not
have full Admin Rights tries to access the FAM...

> A file association manager inside OOo does not make sense at all and
> especially on Vista is a No-No.

It makes *perfect* sense, due to its nature (a full Office Suite that has the
ability to take over File Associations of another Office Suite) - even in Vista...

As I said - I do understand that this ability must be limited to a User who is
logged in with Administrative Rights, and that changes affect all users (just as
they do at install time).

Again, not *one* argument I have ever heard against having a File Associations
Manager built into OOo makes any sense to me...

I don't think that it makes sense to add a function that only works properly if
the user has admin rights.

We should put our UX team in charge of this.

Why not? That is a silly statement, anyway - the Multi-User Installer *itself*
*requires* Admin Rights... so why is *that* ok, but not to have a related
function that also requires it?

Besides - if OOo can be installed as an ordinary user, then it can manipulate
file associations as that ordinary user in the same way. It does so *now*,
doesn't it?

This isn't rocket science... it is very simple... OOo allows for installation on
a Windows machine in two different modes: Multi-user (requires Admin Rights) or
for Single User.

If OOo can correctly set the file associations at install time, for each of
these two modes, it should be able to MANAGE these changes as well.

It should be smart enough to know *how* it was installed (as an Admin, for 'All
Users', or as a normal user, only for that user). The FAM should then behave in
accordance with how it was installed - meaning:

1. If it was installed by an Admin in Multi-user mode, then it should require
Admin rights to manipulate File Associations - just like it requires Admin
Rights to install/uninstall it.

2. If it was installed in Single-User mode, then the FAM should behave
accordingly (however OOo handles single user installation File Association
modifications currently).

Yes, the installer needs admin rights. And of course I don't complain against a
file association repair in the setup. In fact, it's only there.

It's common sense nowadays that applications should not require admin rights.
And so I think we shouldn't add functions to a program that need admin rights.

But let's wait for the input from our UX experts. 

Hello, and thanks for taking the time to consider my comments...

The 'File Association Repair' only *attempts* to reset them - it does not
check/repair permissions if the perms on the registry settings that store them
get muffed, nor does it report a failure to properly set them if it fails - and
this has happened to me at least 4 or 5 times in the years that I have been
using OOo.

I'm *not* saying that it was OOo that muffed them - but I *am* saying that if
they can be repaired manually (by changing perms), then they can be repaired
automatically (as long as the repair attempt is run by a user with admin rights).

There is no reason that a properly coded FAM couldn't test if current user has
admin rights, and if so, it is 'enabled' in the GUI - if not, it is greyed out,
with a message saying that this functionality requires being logged in as a user
with admin rights.

If the User has admin rights, then the FAM could easily test if required
registry settings exist - if not, create them - then test if the perms on them
are correct - if not, reset them - then, change the File Associations to
whatever the user is requesting.

Of course, if the filesystem itself is corrupted, then there is nothing that OOo
can or should do about that, except maybe provide an error message to this effect.

Lastly, I have had a *lot* of cases where I would like to be able to easily
switch back and forth the Microsoft Office associations between MSO (or whatever
they were set to before the OOo install) and OOo (including proper Template
behavior) - but OOo doesn't record their previous state, so there is no way to
do this.

Providing this ability directly in the GUI preferences will only instill a new
level of confidence with people who want to test OOo out side by side with MSO.

Due to correct issue handling setting this issue to new

I want to put in my vote for not including this in the UI.  It sounds like the
repair functionality is just broken.  It should detect a permission error when
it tries to fix the issue and in theory either fix the issue (change back to
default permissions) or at least give an error if it can't (for non-admin users
if the app doesn't have enough permissions).

Adding the UI seems like a kludge to me.  It is to fix a specific issue that is
usually fixed in another way by most Windows programs (at least that I can think
of).

I do agree it should be relatively easy to implement for people that already
know how the code works, but that isn't me...and I feel like this isn't a
stretch to have the user assume they need to run the repair from the installer.

You must have missed my prior comment...

THE REPAIR OFTEN FAILS. PERIOD.

Also, the KLUDGE of 'fixing' them by 'right-click', 'Open-with', check box
'Always use this program...' simply does not work for all situations. One MAJOR
issue is with TEMPLATES. If I do this for a template, it then OPENS templates
just as if it were a normal document, instead of creating a new blank document
BASED on the template.

Also, with this as part of the GUI, it would be very easy to not only repair
file associations, but to RESET THEM TO WHAT THEY WERE BEFORE OOo WAS INSTALLED.

Of course - all I can do is beg someone who is in a position to do something
about this to see the value... it is just very frustrating to know that this
problem - which is a very major hassle when it rears its ugly head - could be so
easily fixed, if the ones who know how to fix it would simply create a simple UI
to let us lowly users do it with a mouseclick or two...

I am totally baffled at why anyone would be against this - it would only

Maybe another option would be a separate utility?

Please?

CCing myself

Ok, I just installed 3.0rc4, and now even the ability to associate Microsoft
Office files during Setup is gone? This was the main reason given in the
responses to this bug I opened being not necessary.

How are we supposed to handle these file associations now??

I was not involved in the decision to remove the association page from setup.
Now OOo will automatically take over the MSO file extensions in case no
application at all is registered for them and it will automatically not take
them over in case there is an application registered.

I think that makes a lot of sense. Removing configuration options where the
application is able to handle that itself reasonably is basically a good idea.
Especially if data is available that proofs that the configuration setting is
misunderstood by many users.

I also understand that "expert" users might want to configure this by themselves
differently. This is a valid request, though IMHO not one with a high priority.
And I still dislike accessing settings for all users from inside an application
(this is also true for other parts of OOo where this is still done, but that's
another story).

Perhaps someone can provide this as an extension?

> Now OOo will automatically take over the MSO file extensions in case no
> application at all is registered for them and it will automatically not
> take them over in case there is an application registered.
> 
> I think that makes a lot of sense.

I agree - to a point. And if you will read this Feature Request, you will see
that this is exactly how I had envisioned this working - with the addition that,
since OOo is CAPABLE of doing this evaluation, AND because it is capable of
making the necessary registry changes, then it only makes sense that this
functionality should be made available in such a way as to be EASILY MANAGED.
Meaning, RECORD the CURRENT registry settings PRIOR to making the changes, and
provide a simple mechanism for MANAGING these registry settings.

> Removing configuration options where the application is able
> to handle that itself reasonably is basically a good idea.

I agree...

> Especially if data is available that proofs that the configuration
> setting is misunderstood by many users.

Again I agree...

> I also understand that "expert" users might want to configure
> this by themselves differently. This is a valid request, though
> IMHO not one with a high priority.

I disagree - VEHEMENTLY.

While I would agree if the functionality were not ALREADY THERE, removing
EXISTING functionality - in essence, DUMBING DOWN an application - just because
the WAY it is currently implemented is confusing to SOME users, is totally
RIDICULOUS.

> Perhaps someone can provide this as an extension?

That would be perfectly acceptable, but the main problem that I have with this
is THE FUNCTIONALITY ALREADY EXISTS. Why should someone else have to reinvent
the wheel?

Just to be clear...

I don't have a problem with the fact that the ability to choose the file
associations at install time was removed.

I have a problem with the fact that NO MECHANISM WAS PROVIDED TO TAKE THE PLACE
OF THIS LOSS OF FUNCTIONALITY.

At a minimum, the devs THEMSELVES - specifically, the one(s) that arbitrarily
and unilaterally decided to remove this CRITICAL functionality should do it NOW.
IMMEDIATELY.

Am I pissed? VERY. Why? BECAUSE WHOEVER DID THIS JUST CAUSED OUR BOSS TO DECIDE
TO SWITCH TO MSO IF THIS IS NOT FIXED PRIOR TO OUR UPGRADING TO VERSION 3.0.

So, if this isn't fixed, OOo just lost an 80+ installed base, just because some
dev somewhere decided they knew better than the people actually USING OOo.

The silence is deafening...

Again... HOW DO I MANAGE THESE FILE ASSOCIATIONS NOW?

Example:

When someone installs the Compatability Pack for Office 2007, it takes over all
file associations, even for normal .doc, etc files)...

With 2.x, this was no problem... simply do a repair install and let OOo take
back the file associations.

Now, I can't even do this.

This absolutely and purely SUCKS.

I had latest stable release, i.e. 3.0.0, installed with no problem regarding
Windows file association. Then I uninstalled it to install the latest
developer's build, i.e. DEV300m37 (Build:9371) at the time, and now Windows file
association is broken with all OO's formats in a way that I could not
re-establish it at all (repair did not help either). Manually association also
fails, because for some reason Windows does not accept any of OO executables to
be added to its "Open with" list. I'm going to uninstall everything and
re-install OO (the dev. build) to see if it takes care of the problem.

Frank, please comment.

I see the status of this was just changed to Whiteboard...

If this means there is actually work going on toward producing something along
the lines of a FAM, then:

1. thanks!

and

2. is it possible that, since I opened the request and this functionality is a
huge personal concern, that I could participate?

Oh - one other comment - most Windows machines already have .doc files
associated with wordpad or notepad... so instead of OOo taking over this
association, it leaves them associated with wordpad... brilliant...

If I hadn't discovered the command-line switches available at install time, my
boss would have switched our entire 80 user base to MSO... as it is, he still
really wants to be able to manage these through the GUI - as do I...

One additional response to the comments about the Repair function being the
solution...

It is *insane* to have to a full repair *installation* when the only thing that
I want to change/repair is the file associations. A repair *installation* takes
*minutes*... a repair/reset/modification to file associations would take mere
seconds.