I have required feature A.feature and optional feature B.feature, latter has plugin B.plugin. I want to move B.plugin to under A.feature.
Similar question has been asked before, but solution requires keeping B.feature as dummy feature for people upgrading, because installing new version of it is required for those who had the plugin installed before, however for new users it's unnecessary noise in update site.
So I tried using patches - currently have set up:
B.plugin - empty, dummy plugin with id as before, will be used in patch
B.patch.feature - includes the dummy B.plugin
A.plugin - copy of old, non-dummy B.plugin with new id
A.feature - includes B.patch.feature, marked as optional, and A.plugin
This seems to work perfectly if B.feature was installed before, but if it's not, then during installing the new version of A.feature the install process it says
B.patch.feature is not applicable to the current configuration and
will not be installed.
and forces user to uncheck B.patch.feature before proceeding.
Is there a way to get it to work or is there another approach to take, ultimate goal being having B.plugin under A.feature in way that B.feature will no longer be seen in update site? Having A.plugin and non-dummy B.plugin active
at the same time causes errors.
Related
I am having hard time understanding Read the Docs version control for my documentation (may be because of lack my understanding!).
All my project documents are hosted on GitHub and I am trying to setup versions for my document that needs to be in-sync with the latest development releases.
How to manage these doc versions/what are the configurations in sphinx config?
Is there a way I can time travel my document. i.e., If I want to see
any older version of my doc, how can I (re)publish this on Read the
Docs?
Currently, what I am doing:
For a particular development release cycle (say rc1.2), I communicate with the engineers for the changes and I make those changes to my doc; merge the feature PR to main branch. On merging, Read the Doc builds a latest version (latest is pointing to main).
How to see the changes for rc1.0, rc1.1. I am thinking of creating something like change_log.rst and list the changes for each releases. But this would be something only for reference. How to manage these in Read the docs on admin/GitHub?
I am writing my first WIX installer. The installed application uses various Microsoft standard OCX controls which are installed as merge modules, for example MSCOMCTL.msm, MSFLXGRD.MSM etc.
For some reason, if the target machine has UAC switched on, running the application after installation fails with a message to the effect that "MSCOMCTL is missing or has not been correctly registered...". However, if the application is run once 'As Administrator' it puts up a UAC "can this app make changes" message (so it's obviously changing something) and then runs fine, and what is more runs forever after without admin privs. (Alternatively, registering the relevant controls with RegSrv works as well).
I have monitored the application with ProcMon and it is obviously doing a late registration. It is as if the installer has advertised the contents of the merge module without installing them. I've also looked at the merge module, and my MSI, with Orca, but I can't work out any way of stopping this behavior.
I did wonder if it was anything to do with the versions of the MSMs, but it seems almost impossible to find out what the latest version of these Microsoft MSMs is, or to find anywhere to download them.
Obviously we do not want to make our customers go through this convoluted process when they install our product. Any suggestions would be greatly appreciated.
Thanks Kiran. We also read that bit in the MSDN documentation. The problem is that we can't alter the Advertise attributes on items that are already built into Microsoft's Merge Modules (well, we could using Orca but it would be messy).
However, I think we may have found the source of the problem. The previous release of our product used a kit built using InstallShield. When we compared the .MSI created by InstallShield to the one created with Wix we noticed that the InstallExecuteSequence table of the IS one contains RegisterProgIdInfo, RegisterClassInfo and RegisterTypeLibraries, which do not appear in the Wix-generated MSI. We think some or all of these may be needed to force the MSMs to install. I need to find out how to put these into Wix, and then to try it to see if it works. I will try to remember to post the result here for posterity.
[Following day] Confirmed. For anyone else who has this problem, you just need to put a <RegisterClassInfo/> tag and a <RegisterProgIdInfo/> tag (and maybe a <RegisterClassLibraries/> tag, but I didn't need one of those) into your <InstallExecuteSequence>.
I know that you can upgrade the versions, remove the old the installation and install the new version.
and I know you can also support two installations of the same software on the same machine.
Is there a way to create a GUI installation which let's the user choose if he wants to upgrade or keep the old version and install the new instance in addition to old the ones?
Yes, but it's not simple.
Basically you start with two upgrade table entries. One that is fake and would never detect a product and one that detects your previous versions but has the DetectOnly attribute set.
Next you need to create a custom dialog with a radio button ( install new, upgrade existing ) and a list box to contain the entries of previously detected products. You will use a custom action to populate the ListBox table with temporary rows to reflect the previous qualifying products to be upgraded.
If the user selects Install new, you just carry on. If they select upgrade existing you parse out the product codes from the Detect Only upgrade action property and put them into the "fake" action property. Now remove existing products will have something to remove.
They are all kinds of business rules you'll want to come up with and enforce, cover the silent installation story and also have a way of mutating the INSTALLDIR so the products can be side by side.
That's the basic pattern but you'll have to come up with all the details around it. I've done this several times with very favorable results.
I'm new to OpenERP and Python too. I have OpenERP 6.0.4
I have modified the invoice.py file in the account folder using python 2.7 (I just edited and saved the file, I didn't compile anything).
The change I made is how the total amount is calculated, I needed the total amount to always add 0.3 EUR to the total.
I then restarted OpenERP server, I also went to admnisitration>modules> set the account module to upgrade and then applied the upgrades.
I then started a new invoice and the changes were not reflected.
For testing purposes, since I'm new to Python and thought maybe I didn't code correctly, I have modified the help message that appears when you hover the mouse over "Residual" in the invoice interface by modifying a line in invoice.py from help="Remaining amount due." to help="This is just for testing."
I restarted the server and upgraded the modules and even this change isn't reflected.
I even created a new database and the modifications are still not showing.
Am I missing something? Is it even possible to edit the core modules ? Is there any workaround to this?
FINAL SOLUTION : Uninstalling and reinstalling the server solved the problem.
The most probable cause is the the addons directory being used is not the same you are editing. You can be sure if you change the name of the addons directory and can restart the server without problems. You can also try to set the --addons-path parameter to the server start command.
If/when you confirm to be working on the right files, try instead to make small text changes on views, since these are visible right after a module upgrade, not requiring a server restart. For instance, try changing some string attributes on account\partner_view.xml.
Slightly off topic, but important: you should not be modifying the core modules directly in the source. The correct way is to extend the core class in your own module which will depend on the core module.
From your comments, it seems you want to add a set tax amount to your invoice. Have a look at http://doc.openerp.com/v6.1/book/3/3_7/invoicing.html#tax-management - openerp already caters for that need and then you dont need to hack the source code which should be your last resort :)
I would like to get an automated changelog from Trac, that will include references to tickets that made some important changes to the architecture/design of the code. My ideal scenario would look like this:
According to some ticket I make a change to SVN
I add some specific line to the ticket saying that this changeset created an important change to the code/wiki
I go to some dedicated Trac page and see a full list of such changes made with the project.
In other words, it's going to be a changelog, which is available for all project participants, and the entire team will be updated about the important changes with source code and wiki.
Can you suggest any Trac plugin for this? Or maybe Trac itself can do it?
ps. Would be excellent to have another "Plans Log", where everybody can post their plans on future changes. Again, inside tickets.
Have you tried the ChangeLogMacro on TrackHacks: http://trac-hacks.org/wiki/ChangeLogMacro
Sample:
[7280] by doki_pen on 12/18/09 20:27:15
Update body reference to output.
Since body isn't defined. Fixes #5538
[7191] by doki_pen on 11/26/09
02:18:32
watch user feature
fixes #3546
[7190] by doki_pen on 11/26/09
02:18:21
copy changes
trying to make things more intuitive
for users
Personally I'm looking for something a little more like the VirtualBox changelog which I can then put into a plain text file. So if anyone knows how to do this I'm interested!
www.virtualbox.org/wiki/Changelog
Sample:
VirtualBox 3.1.2 (released 2009-12-17)
This is a maintenance release. The following items were fixed and/or added:
VMM: fixed SMP stability regression
USB: fixed USB related host crashes on 64 bits Windows hosts (#5237)
Main: wrong default HWVirtExExclusive value for new VMs (bug #5664)
Main: DVD passthrough setting was lost (bug #5681)
VBoxManage: iSCSI disks do not support adding a comment (bug #4460)
VBoxManage: added missing --cpus and --memory options to OVF --import
VirtualBox 3.1.0 (released 2009-11-30)
This version is a major update. The following major new features were added:
* Teleportation (aka live migration); migrate a live VM session from one host to another (see the manual for more information)
* ...