[Issuetracker-development] IssueTrackerProduct advanced new features. Please discuss.

[Peter B. <ma...@pe...>]

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