[Issuetracker-development] IssueTrackerProduct advanced new features. Please discuss.
Brought to you by:
peterbe
From: Peter B. <ma...@pe...> - 2003-02-03 04:28:19
|
First of all:: I send out this message to the issuetracker mailinglist and to all people who have shown interest in the IssueTrackerProduct via email. If I've double-emailed you or you do not want to get any more emails from me about the IssueTracker I sincerely appologise and you can tell me so. Prolog:: Judging from the results of the survey I have, and still am, conducted a lot of people seem to want to be able to use more advanced teamwork features. Mainly it's to be able to assign things to people and add a few more permission layers of authenticated people and what they can do. Sure I say! But these are the conditions: 1. These features will be by default switched off 2. One must be able to swich back and forth between these features without breaking anything 3. Authentication must be basic Zope authentication, with the option of Remember Me Below these different new features (NF) are discussed. Please chip in with feedback. No deadlines are yet promised. NF1:- store log of how issues change status:: Something like this [{'status':'open', 'changedate':ZopeTime('2003-01-30'), 'actor':'peterbe'}, {'status':'completed', 'changedate':ZopeTime('2003-02-11'), 'actor':'Some Stranger <str...@ho...>'}, ...] This way, one could inspect the historical development of an issue. and measure the time between two changes. NF2:- assignees/stored users Assignees will basically be a set of different Zope Roles (great, then we can use acquisition!). To be able to integrate this seamlessly without breaking anything I intend not to use the builtin security mechanisms. Rather I'd just use that as a storage base. ACL users do not have any other information than userid and password but the email address is important, therefore I suggest a matching property that can look this this:: {'peterbe':{'email':'ma...@pe...', 'name':'Peter'}, 'fred':{'email':'fre...@as...', 'name':'Fred Blogs'}, ...} It's expected to be unlikely that an ACL user is not associated with an email address. Most likely this will happen when a zope Manager Views the issue tracker. Tough luck I say, then we can fall back on cookies like it is today. I will define a bunch of Roles for all instances. What about these:: - Manager Can do everything outside the ZMI. (this role the real Zope Manager will be assumed to take) Access to certain statistical conclusions. - Worker Can do everything except Deleteing and Changing already defined issue attributes. - Client Just like Zope Anonymous works today. Setting these up will create special objects. That way, if you decide, you can call a Manager "Project Manager" or "Boss" instead if that suits your environment better. Suggestions will be available when you create them. I would like to be able to have this completely up to the administrator of the issue tracker but I'd both provide suggestions and some pre-created ones. The Remember Me would require that you store a cookie with the user, and do an automatic Basic Authentication login. What about register/signing up? Should only Zope administrators be able to control this? Or should it be possible for a say Managers to create registration templates for people who have not yet signed up? The note NF1 above can be used to conclude whether certain assignees can do certain things to issues. I.e. if you're only a "Worker" you should only be able to Complete- or Delete- or both issues that you yourself created. NF3:- due dates:: Will obviously require a cronjob attached to the issue tracker. Don't like this idea but it has to be so, maybe I can nick code from the Xron Method Product to make the issue tracker product non-dependable. When you add an issue you're supposed to be able to select a date when an issues must reach a certain status, and optionally for whom. I.e. this issue should be completed by John by the 11th of June. This requires a calendar widget of some kind. I suggest a javascript calendar which pops up with an input field. Code can be nicked from the Calendar Tag or CMFCalendar/CMFPlone. (Maybe somebody can help me extract the appropriate code from CMFPlone for me?) Another thing. What do I call this new feature project? I'd like to be see this particular word as a Tab in the ZMI. Suggestions:: - Teamwork - Team - People - Users - Advanced Permissions - Collaboration - - Best regards, Peter |