Behavior schema

[seanupton]

We need schema interfaces for behaviors and types:

• Must be Python interfaces, not using supermodel XML
• Should reflect needs for both planner/container (default placeful config) and individual tasks.

My sense of this (irrespective of how we actually implement re: re-using collective.task):

Should reflect state from view mock (plus assigned party/parties):

[seanupton]

I think it is a given that we will need to add collective.z3cform.datagridfield as a dependency, thus #11.

[aclark4life]

@seanupton To clarify, by "Must be Python interfaces, not using supermodel XML" you mean supermodel models with zope schema defined in Python not XML, correct?

[seanupton]

@aclark4life yes, I want to have schema defined in either an interfaces.py or behaviors.py file, I don't want to load from XML, because IIRC you cannot subclass these.

[aclark4life]

@seanupton Please review content, behaviors, and interfaces and please clarify/confirm the following:

• The mockup shows task add form with "assigned task (due date, computed due date, notifications)" behavior enabled.
• Computed due date and notifications schema are made explicitly (vs. conditionally) available to the Task when "assigned task" behavior is enabled.
• Interfaces without <<>> designation are assumed to be provided by IAssignedTask behavior
• Mockup form fields should be implemented via collective.z3cform.datagridfield
• You have more mockups coming for other application features e.g. task status view and task planner type

[seanupton]

@aclark4life My assumptions:

1. The mockup reflects some separate "Task assignment" view/tab (object action) on any content item with the behavior interface (conditional via TALES expression on action).
2. Yes, rules for computation of date due, notifications available to all task-like content.
3. May be slightly off-topic: the actual due datetime computed need not be stored, necessarily. There are some issues:
   • The trick of course is that not storing/indexing computed due dates makes enumerating-by-principal tricky. Computing this just-in-time for display on the task is easy; computing this for a portlet or search-like view for users to find their own (upcoming, overdue) tasks is more work to do just-in-time without some sort of due date saved.
   • I have no objection to using portal catalog for an extra index, but no inclination either. There are trade-offs either way (vs. storing tasks in some other data structure like an annotation accessible off the site-root that is accessed by adapter-of-site).
   • Re-computing task due date/time on IObjectModified of task or parent/containing planner (or similar like content using behaviors) might be easy enough.
   • An out-of-band (dedicated process, maybe a run script controlled by supervisord as an ad-hoc daemon) task notification system need not store these things as long as it can compute just-in-time.
4. Generally, the interfaces without the <<>> stereotypes are provided by either IAssignedTask or the ITaskPlanner behavior interface, I think. The planner/container does not support explicit due_on (due date) field (I'm not sure what effect this assumption has on any possible support for recurrence).
5. Yeah, I am assuming collective.z3cform.datagridfield, unless something newer/better exists, for enumerating 0..N notification rules.
6. The mockup provided so far is not very different from task-planner, other than planner has no explicit due-date (just the rules below it for computing due, notifications).
7. I will need to consider view/UI implications for displaying status. My sense is that this could be a (pretty minimal) viewlet (a "one-line" strip of status info) in the plone.abovecontentbody manager (in Plone 4). I will also need to document possible ideas about injecting task status change history into workflow_history on the object.

[seanupton]

@aclark4life I think we want me to enumerate the vocabulary for all the choice fields ASAP; aside from the implied options in some of the drop-downs shown in mock-up image, this is not documented yet.

Let me know where you want me to do that? I can just check in some vocabularies for everything with a static vocab (which AFAICT is all fields but the principals) into interfaces.py on master if that makes sense.

[aclark4life]

@seanupton That's fine, please do! Thanks

[seanupton]

https://github.com/upiq/uu.task/commit/e8f57d51e8b1432e0934a01c7d7543e40327c814 has some static vocabularies for some choice drop-downs.

[aclark4life]

Thanks

[aclark4life]

@garbas Looking good as of afaca58bf227af14d5625f1347a03ea674e1fd35 thanks.

Suggestion

On load of the assigned tab, the form tab looks like this. After selecting "computed due date" and returning to "due date" it looks like this: I think the form should look like the latter image always i.e. even on form load.