User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:18.104.22.168) Gecko/20060508 (CK-NSS) Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:126.96.36.199) Gecko/20060508 (CK-NSS) Firefox/188.8.131.52 Although I believe this is platform independent, I have only tried it on Sun Sparc Solaris. This is an enhancement request rather than a bug report, but in my opinion CCK would be much more useful if the described functionality were added. Currently, if you create a customization extension using CCK and install it "globally" so that it applies to all users of a server based Firefox installation (i.e. using the -install-global-extension flag to install the extension under $FFOX_HOME/extensions rather than $HOME/.mozilla/firefox/extensions), the customizations are only applied the first time a user starts Firefox. If you subsequently want to alter the extension, for example to update corporate bookmarks or proxy servers, simply removing and reinstalling the global extension does *NOT* produce the desired outcome of having every user's environment updated. I thought that manually overriding the cck.<company id>.initialized preference on each client might be a kludgy workaround, but doing so simply adds in the new customizations, it does not remove customizations that the previous extension added. Reproducible: Always Steps to Reproduce: 1.Create an extension using CCK which adds a single bookmark. Use company identifier "TEST". 2.Install the extension globally into $FFOX_HOME/extensions directory of a shared firefox installation using the firefox -install-global-extension flag (e.g. as user ff_owner) 3.Start up a user session of firefox (e.g. as user ff_user) and see that the bookmark is present as expected. 4. Quit the user session of firefox. 5. Create an updated version of the extension using CCK (e.g. change the bookmark description and URL) 6. As user ff_owner, uninstall the old version of the extension and restart firefox. 7. As user ff_owner, install the new version of the extension and exit firefox 8. As user ff_user, start firefox and note that the new bookmark does *NOT* appear. 9. As user ff_user, reset the cck.TEST.initialized value to FALSE on the about:config "page". 10. As user ff_user, exit and restart firefox. Rather than seeing the expected single (new) bookmark, both the old and the new one will be present. As far as I know, there is no way to get rid of the old bookmark (other than manually visiting each user's workstation) because the CCK generated extension does not include any version information in the bookmark it creates. In effect, as soon as the customization extension finishes creating custom bookmarks, they become the user's bookmarks which are not associated with the customization extension in any way. Actual Results: After upgrading a globally installed, CCK generated customization extension, user environments are not updated properly. Expected Results: Upgrading a globally installed CCK generated customization extension should cause user's environments to match what was specified in the new version of the extension. Customizations from previous versions of the customization extension should be removed. I would propose the following: 1) Rather than using a binary property (e.g. cck.TEST.initialized=[TRUE|FALSE], use a string property which records the version number of the customization extension that was last initialized. For example, this might be NULL until you installed version 1.0. Once you ran 1.0 the first time, it would become 1.0. If you then upgraded to version 1.0_new and reran, it would become 1.0_new. 2) Store the company id and version number along with any customizations done by a particular version of CCK generated extensions. For example, bookmarks might include the tags CCK_CO_ID="TEST" and CCK_VER="1.0". 3) On startup, firefox should check the version of the CCK extension installed (globally or locally). If no previous version was installed, it could simply go ahead. If a different version (just different, not necc. higher or lower) was previously initialized, it should remove all of the previous customizations prior to initializing the new ones. If the same version was previously installed, no action would be required. NOTE: For bookmarks, you can partially get around the problem described in this bugreport by creating a single "live bookmark" via a CCK created extension and linking this bookmark to a XML file on a shared filesystem or webserver. When changes to the bookmarks are required, you can simply manually update the XML file and the changes will be seen the next time the user opens firefox. Crude but it works. NOTE: For preferences (including proxy settings, etc.), the mozilla autoconfig feature which is now installed by default works fine for shared installations, and updates *DO* produce the desired change in user environment. For this reason, we are using CCK only for things that autoconfig can't handle such as browser title, help menu links, bookmarks, etc. Thus, for purely selfish reasons :-), we'd prefer to see the functionality above applied to these GUI resources first.
I have yet to come up with a creative way to do this. Basically, once I create the bookmarks, I have no record that I Created them, so I can't remove them when the CCK is uninstalled, and I can't know that they need to be replaced. I'm open to ideas :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well, I won't have to program it so it's easy to suggest things, but here goes: IDEA 1: In the bookmark manager, right clicking "Properties" on a separator allows you to add a name for the separator (e.g. CCK_BOOKMARKS_START). What about placing any CCK generated bookmarks between separators that have names like CCK_BOOKMARKS_START and CCK_BOOKMARKS_END? IDEA 2: It would be crude, but what about adding an "encoded" text field to the description portion of all CCK generated bookmarks. Something like [CCK_START|This text added by CCK, do not update or delete it!|CCK_CO_ID=TEST|CCK_VER=1.0_new|CCK_END] The user would be free to put whatever they wanted in front of this text, but as long as they didn't muck with the stuff between the "[CCK_START" and "CCK_END]" then CCK could parse out the required info. It seems like the description portion of bookmarks is common to folders and individual bookmarks, yet doesn't actually show up in the running browser except when you are in the bookmark manager. Below is a snippet from my bookmarks.html file, created with the bookmark manager, illustrating both of the ideas above: <DT><A HREF="http://www.mozilla.com/products/firefox/central.html" LAST_CHARSET="ISO-8859-1" ID="rdf:#$GvPhC3">Getting Started</A> <HR NAME="CCK_BOOKMARKS_START"> <DT><A HREF="http://www.google.com" ADD_DATE="1147732510" LAST_MODIFIED="1148416977" ID="rdf:#$YygBc1">Google</A> <DD>[CCK_START|This text added by CCK, do not update or delete it!|CCK_CO_ID=TEST|CCK_VER=1.0_new|CCK_END] <DT><A ADD_DATE="1147732510" LAST_MODIFIED="1148416629" FEEDURL="file:///home/HELP/pss_bookmarks.xml" ID="rdf:#$ZygBc1">NSS Bookmarks</A> <HR NAME="CCK_BOOKMARKS_END">
OK, I can actually implement this with the new Places stuff on Firefox 3. So I need some opinions. Should I allow users to move the CCK generated bookmarks around and delete them, etc. and only recreate them when a CCK is upgraded for instance? Or should the bookmarks only be created once at CCK start and then removed at CCK uninstall? What if the user disables a CCK? Should the bookmarks get removed? Thanks for your input.
Our use is to present a "standard" corporate set of bookmarks, so for us allowing users to update would not be a priority. In fact, it might be better if they can't modify them. So, I would (selfishly) say: - don't allow users to modify CCK generated bookmarks - bookmarks should be created when CCK is installed and removed when it is uninstalled - bookmarks should be removed if the CCK is disabled This is just my 2 cents - if you find a compelling reason to do things differently while still supporting the goal of supporting a "standardized", server based Firefox install then I'd be happy. Thanks for keeping this request alive!
OK, so here are some things I can and cannot do. I cannot make individual bookmarks read only (not deletable) I CAN make a folder readonly: * If this is set to true, UI will not allow the user to add, remove, * or reorder children in this folder. The default for all folders is false. I can delete and recreate the bookmarks on each close/opening of the CCK. So here are some options given this info. These could be settable in the CCK. And they are not mutually exclusive. Option 1: Allow any folder in the CCK Wizard UI to be marked as "readonly" and I can set it as that. Option 2: Have a preference that says "recreate bookmarks every time browser is started. Note this will probably annoy users, but might be useful for some companies Option 3 (will probably be the default): Remove bookmarks if CCK is disabled or uninstalled. If this is the case, readd bookmarks when CCK is enabled or reinstalled. Note that this should cover the upgrade case. That is, I'll check to see if we are being upgraded, and if so remove all the bookmarks and readd them. I could probably be smarter and only remove the ones that aren't there or add the ones that are new, but that seems like a lot of work for this problem.
One other caveat. I'll be checking for the presence of bookmarks to decide if they need to be created (as opposed to the old way that used a preference) So if a user deleted ALL the bookmarks the CCK added, they would get readded.
OK, here is how it is going to work. I add the bookmarks on install and mark them with the ID and version of the CCK. When the CCK is disabled or uninstalled, I delete them. If you upgrade the CCK to a new version, I remove the old ones and add the new ones. There are two downsides to this method which I think are acceptable. 1. If you remove ALL CCK generated bookmarks, they get regenerated. (I'm working on this one, don't think I'll find a solution) 2. If you've customized the locations of some of the bookmarks, on upgrade they'll get reset to their original positions (nothing I can do about this) How does this sound?
It sounds great! This addresses the issue as far as I'm concerned. Thanks for fixing this.
There's one more thing that is going to happen here and I don't think I can work around it. When a user upgrades from FF2 to FF3, bookmarks will be duplicated. I could attempt to see if the bookmarks already exist, but I would run into problems with separators and other things.
Have you tested this with a latest CCK to see if it meets your needs? I have a separate request to make these bookmarks identifiers customizable with each CCK so that the bookmarks versions are independent of the CCK versions. This should make things even better.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.