Research: evaluate suitability of building on top of collective.task

[seanupton]

Research (unreleased) collective.task package as a possible framework to extend or build on top of. We need to assess:

• How complete is it now?
• How does it overlap with our stated requirements? Where does it not?

We likely want to install this in a Plone 4.3 site for testing, evaluation. There should be some discussion of pros/cons of using this. We can always refactor what we are doing toward an aim of future collaboration if necessity dictates.

[aclark4life]

Thanks, any other add-ons to research? Or is collective.task the only one worth considering? I see very few:

$ pip search task | grep -i plone       
izug.ticketbox            - A tracker-like task management system for plone.
Products.cron4plone       - cron4plone can do scheduled tasks in Plone
ftw.task                  - A simple task content type for Plone.

But thought I'd ask.

[seanupton]

@aclark4life only looking seriously at stuff that is Dexterity-based (none of the above), but might make sense to spend a bit of time reviewing them for basic ideas (along with Products.Poi and your own previous task/project add-ons)?

[aclark4life]

Got it, thanks

[seanupton]

@aclark4life some random notes:

• We might want to inquire upstream with collective.task author(s) about supporting more than one assigned principal/party? AFAICT, does this only supports single-party assignment? This might be YAGNI in most cases, but ideally we would have a way to support more than one assigned party in some small minority of situations.
  • Not sure if LocalRoleMasterSelectField supports the dependent field being a Set-of-Choice, though?
• Currently, collective.task uses Date, not Datetime for due_date. Ideally this would be a datetime (e.g. "Your forms are due at 5 p.m. the first Friday of each month")?
  • I also recognize this presents issues of dealing with timezone, which I have some thoughts about (handling similarly to plone.app.event).
• In Plone 4.3.4+ (plone.autoform 1.6.1+) it is possible for multiple behaviors to add to the same fieldset; if we add another behavior for additional fields to supplement what is in collective.task.behaviors.ITaskWithFieldset, we should add to the 'task' fieldset it already defines.
  • I am assuming we will have some kind of additional behavior interface, perhaps called something like "ITaskRules".
• Schema misc:
  • Presumed that our tasks have optional start, end (datetime) fields.
  • Fields for calculated due date+time (relative to start/end in either hours or days).
  • Fields for calculated notification date+time (relative to due date, in either hours or days).
    • Unsure if we should support multiple notification times (e.g. using collective.z3cform.datagridfield where multiple rows of notification rules can be added).

[aclark4life]

@seanupton Re: multi-principal, do groups count i.e. one or more users who are members of a group. Or do you want "true" multi-principal support e.g. one or more users, one or more groups?

[aclark4life]

Opened collective/collective.task#2

[seanupton]

@aclark4life wondering about maybe just supporting singular assignment with the possibility of grafting on a "Cc" field at later date.

The other concern re: c.task was mostly that due date was date, not datetime (my sense is that this would be easier to work around).

[aclark4life]

Punt