Is there an easy way to disable builtin apps (or shadow them with our own)? Most of them work fine out of the box, but bc_desktop has required heavy surgery to get running.
The issue going forward is that this tree (/var/www/ood/apps/sys/bc_desktop) is in the distrubtion RPM, so presumably when we next upgrade that, our local stuff will get stomped. An obvious solution is to call our version something else (e.g., bc_our_desktop). But if I understand correctly, the original non-functioning desktop will still show up in menus. How do we stop that?
For the record, at least for bc_desktop, the answer seems to be to edit /etc/ood/config/apps/bc_desktop/.yml and change the value of “cluster” to something like “disabled”. Apparently apps won’t be displayed if the name of the cluster doesn’t match your cluster’s name.
Call your version something else and ensure the /etc/ood/config/apps/bc_desktop is renamed to the directory name matching your modified version. For example /var/www/ood/apps/sys/bc_our_desktop and /etc/ood/config/apps/bc_our_desktop. You can also move the directory in /etc under the app directory at /var/www/ood/apps/sys/bc_our_desktop/local/
As long as there is no /etc/ood/config/apps/bc_desktop the original desktop app shouldn’t appear in the menu.
This approach doesn’t work for the Passenger apps though.
That’s true, if the /etc/ood/config/apps/bc_desktop/.yml has an illegal value for cluster it will be an “invalid batch connect app” and then it will not display in the menu.
Thanks for your replies. This is pretty much where we ended up, though we actually have no config files for bc_our_desktop at all. This seems to work, though we do have a “cluster: ourcluster” element in form.yaml. (Arguably bad style, but convenient for us.)
Yea in 1.8 the logic for invalid batch connect apps changed a bit to make it more lenient.
I think the strategy you’d want to employ now is to change the permissions of /var/www/ood/apps/sys/bc_desktop so that it’s not readable by regular users. Then it won’t show up.