RE: [Zope] Design question for a problem tracking Systems using Z ope
1. user management ================== For managing users, I like the idea of using LDAP authentication. You can store just anything you want in the directory (and typical directories already store the email and phone numbers for users).
2. Bunch of DTML Documents + Factory methods vs. SQL database ============================================================= I know how to do the SQL thing, but the document thing seems nice to me. But is it possible using Zope?
Very possible. This is my next project. Bug Tracking is exactly a set of linked documents. ZODB + ZCatalog is a much better match than a relational DBMS. <insert here all of the well-known problems with mapping objects to rows, and managing semi-structured data, which are solved immediately by using an Object Database> 3. What Objects should exist? ============================================================= Here is my take for a Bug Tracking System design: each "Change Request" has these important sections: Identification Status Workflow Attachments Related Documents Disscussion Identification doc# (for cross references) summary/title description product/module/version/build type { Bug, Feature, ... } severity { show-stopper, critical, has-workaround, cosmetic, who-cares, ...} reproduciblity reporter Status owner status { new, assigned, ..., resolved } priority target fix date/build visibility (public/securty-issue/private) <rant> I have a major gripe with this one wrt Open Source projects: everything should be public, unless there is a major security issue involved. I find the Zope collector very annoying in this respect. If DC wants help fixing the bugs, people have to know what the bugs are. This field is important for closed projects. </rant> Workflow can be as simple or as complex as you want it. It should probably include a change history for at least the Status section. Attachments screen shots, test cases, etc. Related Documents Other change requests requirements docs design docs test plans/test cases version control info (e.g. when was the fix checked in?, what checkin broke it?) Discussion Confera works nicely for the Discussion section: simply create a Topic within the document. An email gateway would also be nice. The "Product Tree" has meta data about where things go. It knows about what products/modules/sub-modules are being developed and who is responsible for them (manager, developer, reviewer, QA, ...) -------------------------- I have seen at least three people mention this application on the list. I believe DC might have one in the works. I think this would be a good open-source project. I am willing to work on this one. -- Terrel ----------- p.s.: sorry for the slow reply. Keeping up with this list is a major task.
I applied the proposed patch def manage_editCataloger(self, default, REQUEST=None): """ """ self.default_catalog=default message = "Your changes have been saved" return self.manage_main(self, REQUEST, manage_tabs_message=message) to use it in <dtml-let obj="Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editCataloger('Catalog1', REQUEST)"> <dtml-call "obj.reindex_object"> </dtml-let> which will not work, because of the return self.manage_main() call. After updating the entry it shows up in Catalog1 as expected, but I would like to have it there directly after inserting the entry. Just to see if I understand the code correctly, I changed manage_editCataloger to def manage_editCataloger(self, default, REQUEST=None): """ """ self.default_catalog=default self.index_object() message = "Your changes have been saved" return self.manage_main(self, REQUEST, manage_tabs_message=message) and after that used <dtml-let obj="Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editCataloger('Catalog1', REQUEST)"> </dtml-let> which works as expected. :-) So, what about def manage_editCataloger(self, default, REQUEST=None, reindex=1): """ """ self.default_catalog=default if reindex: self.index_object() message = "Your changes have been saved" return self.manage_main(self, REQUEST, manage_tabs_message=message) or is there a better solution? -- Tom
At 06:27 9-10-99 , Tom wrote:
I applied the proposed patch
def manage_editCataloger(self, default, REQUEST=None): """ """ self.default_catalog=default message = "Your changes have been saved" return self.manage_main(self, REQUEST, manage_tabs_message=message)
to use it in
<dtml-let obj="Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editCataloger('Catalog1', REQUEST)"> <dtml-call "obj.reindex_object"> </dtml-let>
This should read: <dtml-with "Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "manage_editCataloger('Catalog1', REQUEST)"> <dtml-call reindex_object> </dtml-with> You didn't call reindex_object, you only asked for it's object reference. Above code will work, altough it is from the top of my head.
which will not work, because of the return self.manage_main() call. After updating the entry it shows up in Catalog1 as expected, but I would like to have it there directly after inserting the entry. Just to see if I understand the code correctly, I changed manage_editCataloger to
The call tag ignores whatever is returned. It doesn't work because "obj.reindex_object" is not the same as "obj.reindex_obj()"
def manage_editCataloger(self, default, REQUEST=None): """ """ self.default_catalog=default self.index_object() message = "Your changes have been saved" return self.manage_main(self, REQUEST, manage_tabs_message=message)
and after that used
<dtml-let obj="Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editCataloger('Catalog1', REQUEST)"> </dtml-let>
which works as expected. :-)
Only because you now actually call reindex_object. Note that manage_edit_cataloger is a method of the ZClass, not of the property sheet. It happens to work because of acquisition.
So, what about
def manage_editCataloger(self, default, REQUEST=None, reindex=1): """ """ self.default_catalog=default if reindex: self.index_object() message = "Your changes have been saved" return self.manage_main(self, REQUEST, manage_tabs_message=message)
or is there a better solution?
See above. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | T: +31 35 7502100 F: +31 35 7502111 | mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ---------------------------------------------
Martijn Pieters wrote:
At 06:27 9-10-99 , Tom wrote:
I applied the proposed patch
<dtml-let obj="Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editCataloger('Catalog1', REQUEST)"> <dtml-call "obj.reindex_object"> </dtml-let>
This should read: <dtml-with "Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "manage_editCataloger('Catalog1', REQUEST)"> <dtml-call reindex_object> </dtml-with>
Uups, I thought I started with exactly this code, but probably I did something wrong. The above code works as expected. Thanks a lot for clarifying this (seems to be a FAQ :-)) Setting default_catalog by a managment screen would be nice but zclassifying CatalogAware gives not much sense, I guess? thanks.. -- Tom
At 13:37 9-10-99 , Tom wrote:
Martijn Pieters wrote:
At 06:27 9-10-99 , Tom wrote:
I applied the proposed patch
<dtml-let obj="Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "obj.propertysheets.daten.manage_editCataloger('Catalog1', REQUEST)"> <dtml-call "obj.reindex_object"> </dtml-let>
This should read: <dtml-with "Firma.createInObjectManager(REQUEST['id'], REQUEST)"> <dtml-call "propertysheets.daten.manage_editProperties(REQUEST)"> <dtml-call "manage_editCataloger('Catalog1', REQUEST)"> <dtml-call reindex_object> </dtml-with>
Uups, I thought I started with exactly this code, but probably I did something wrong. The above code works as expected. Thanks a lot for clarifying this (seems to be a FAQ :-))
Setting default_catalog by a managment screen would be nice but zclassifying CatalogAware gives not much sense, I guess?
There is a management screen for it. Just add manage_editCatalogerForm to the URL of an instance of your ZClass. But as this is a textbox (not a popup of all available catalogs) and you usually do not want anyone to chenge the default catalog, this isn't much use right now. DC is working on this I believe. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | T: +31 35 7502100 F: +31 35 7502111 | mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ---------------------------------------------
participants (3)
-
Martijn Pieters -
Terrel Shumway -
Tom