Hi there, Yesterday I released ZFormulator 0.1. I've run into a problem with Zope security settings with it now. I would appreciate it a lot if anyone knowledgable and daring enough would take a look at the file Form.py in ZFormulator. The symptoms are as following: I've been developing ZFormulator logged in as the Zope superuser. Apparently this Zope superuser has powers above the manager role, as ZFormulator works for the superuser, but not for the manager. I don't know exactly why, but I do know I am doing a lot of hacking in Form.py that might be causing it. Here I'll describe some of the hackery. It is probably completely incomprehensible if you haven't at least tried to read Form.py in ZFormulator first (or are reading it while you read this post). Also check out __init__.py to see how Form.py is used from the other side. In order to be able to easily register new field classes with Zope, without having to do a lot of boring code duplication (which would mean also maintenance hassles), I've tried to shield the Python programmer as much as possible from Zope itself. Form.py contains, besides the code implementing ZFormulatorForm, also code to register fields with it. The normal way to register a product in Zope is to tell Zope about a manage_add method, and a manage_addForm. In ZFormulator I only have a single manage_add method (which receives from the manage_add Form which field to add), and I dynamically add manage_addForm methods for each registered field (in the form manage_add<field meta_type>Form). These Forms cannot be HTMLFile objects, because they should be rendered differently for each field that is added. Because I could not figure out a way to pass extra information to the HTMLFile object when it's called, I decided not to use them, and wrote a custom class instead to produce the right form. Unfortunately, a mechanism in OFS/CopySupport.py needed when doing a copy & paste or a rename of an object in the Zope management interface, didn't like my custom class. It was looking for some mysterious (to me) attribute __roles__, and didn't find it. So while I was doing hacks anyway, I manually added in a __roles__ attribute to the FormHack class. After that renaming and copy and pasting *appeared* to work, though I've had some odd results after a rename recently, so I'm not entirely sure. This is one possible cause of the bug. A less hackish solution to all this would be appreciated, in any case. There's another possibility, however. Because the manage_add<meta_type>Form methods are added dynamically to the Form class, I can't include these Forms in the __ac_permissions__ of that class. So, I reasoned perhaps the superuser isn't bothered by this lack of permission information, but normal managers are, and thus can't access the form because they have no permission to do so. It seems like this is not the case however; I added yet more hackery stuff to the registration code, this time modifying the __ac_permissions__ attribute. If my hack went right the Forms *should* be part of __ac_permissions__ now and the manager ought to have no problems. But the problem persisted, so I don't think this is the solution. In general, I'd like to know if there's some better way to accomplish what I want without resorting to such hacking. To make my framework work well currently I *do* need it; I don't want to have to write an identical add<meta_type>Form.dtml file for each field that I add, I don't want to have to edit the __ac_permission__ attribute of the Form class for each field I add, I don't want to have to add manage_addForm methods to the Form class manually. Right now the framework works pretty nicely, shielding you from all that. Unfortunately it doesn't work properly yet... So, Zope gurus, *please* *please* take a look at Form.py. Please save me from all these kludges! Regards, Martijn