(dedicated to davisagli on Plone irc for taking the time to teach this old lady a new trick!)
Integrators are a special breed (if I do say so myself). Especially small-business-owning integrators who wear multiple hats, sometimes begrudgingly. One of those hats is troubleshooting issues that the client feels is important. The developers job is done and an issue has come up that was caused by a small change or request by the client, unrelated or a distant relation to the original specs for the project. It’s not really scope creep but it’s enough of an annoyance to the client that we as integrators are compelled to take care of it. We didn’t write the original product, maybe we hired someone or we are using a third-party product. Sometimes the actual solution is outside of our realm of knowledge so we seek out our peers to help us resolve it.
In this case we had a product called CaseStudy for a university. The CaseStudy product was subclassed from another content type (the File content type). The CaseStudy type was basically a file and a few fields so it made sense to subclass from that content type.
The product was installed and testing began. As part of the process a custom view would be implemented for the CaseStudy collection and for the CaseStudy project page. These were not an issue, views were created and added (I’ll write a post on how to add a custom view to your product and how to deal with multiple views).
There was one issue, when you clicked on an item (the link to open the CaseStudy project page) a download box would pop up. The expected result when clicking on the CaseStudy project page link was to go to the CaseStudy project page.
The quick & dirty Zope Management Interface fix was the following:
- Go to the ZMI
- Find portal_properties/site_properties
- find typesUseViewActionInListings field
- Add your content type – ours was CaseStudy
- Save changes
Now when we clicked on the link for our CaseStudy it went to the right view.
If you want to move this to your product so that the next time you install your product this will work correctly, do the following.
- In your ZMI go to portal_setup
- Click on the export tab
- Find Plone Properties (#15 on my setup)
- Click the checkbox next to Plone Properties
- Scroll down and select “Export Selected Steps”
- Save the file to your desktop
- Unpack the zip file and save the file (propertiestool.xml) to your desktop
It will look like this:
So now you have something that looks like this, scary isn’t it?
For your own product you don’t have to include the entire base file from Plone’s propertiestool as long as you include purge=false within the property tag. The purge=false acts as a way to attach this new property name to the original properties file. If you don’t add purge=false you will break your properties because it will only use what you have included in your xml file.
Our propertiestools.xml file (in /profiles/default) looks like this:
<?xml version="1.0"?> <object name="portal_properties" meta_type="Plone Properties Tool"> <property name="typesUseViewActionInListings" type="lines" purge="false"> <element value="CaseStudy"/> </property> </object>
I hope this helps someone. I’ll be making changes to this as I learn more about Generic Setup and using it to export/import steps.
Rather than adding your file to /profiles/default on your file system you can also import the propertiestool.xml file using the import tab in portal_setup.
I haven’t done that yet. I’ll add that direction once I have.
