Log file Viewer

[11:22:28] <garbas> aclark: i'm getting at the point where i would need some input on the ui/ux of the widgets to make "final" customizations

[12:03:31] <aclark> garbas: k

[12:03:53] <aclark> garbas: final customizations meaning field names? or something else…

[12:04:11] <garbas> aclark: as in: how to show things

[12:04:40] <aclark> garbas: I'm going to start parsing the latest from supton, should have something in 45 min or so

[12:04:44] <aclark> ah, ok

[12:04:57] <aclark> well, i can take a look

[12:05:01] <garbas> aclark: especially i would like to know how to show values from TaskPlanner

[12:05:34] <garbas> currently i'm just showing it in a raw format, but i guess we want something prettier

[12:05:43] <aclark> i think he is more concerned with how to use them programatically then how we display them

[12:05:47] <aclark> let me dig up some comments

[12:06:10] <aclark> !google programatically

[12:06:10] <pmxbot> http://english.stackexchange.com/questions/12245/frequent-use-of-word-not-found-in-dictionary-programatically - Frequent use of word not found in dictionary, &quot;programatically.&quot;

[12:06:19] <aclark> hah

[12:07:05] <aclark> garbas: btw did you see: https://github.com/blog/2020-improved-organization-permissions ?

[12:07:11] <garbas> no worries, i dont notice :) i do to many mistakes myself

[12:07:19] <aclark> collective has it now, which has problably broken everything ;-)

[12:07:20] <aclark> heh

[12:07:40] <garbas> just now

[12:11:28] <aclark> garbas: ok here's key comments from supton from yesterday:

[12:11:50] <aclark> 2015-07-20 21:08:35suptonFor "task planner" I just care that the task getters/indexers fall back to the container's values

[12:12:40] <aclark> i.e. walk up parent objects looking for values, until task planner is found, so don't walk up parents above that stop state

[12:12:59] <aclark> he raised some concern about making sure we don't use Zope2 AQ to do this…

[12:13:19] <garbas> yup. that is all being done.

[12:13:23] <aclark> which makes sense since I don't think anyone relies on AQ anymore anyway

[12:13:24] <garbas> well not the getters part

[12:13:31] <garbas> but i can add that as well

[12:13:47] <garbas> +1 no AQ

[12:13:50] <aclark> how would we do getters? ok great thanks

[12:14:21] <aclark> next: notification daemon, I am mostly concerned that its indexing/property access needs are met this week.

[12:14:31] <aclark> And then he lists a bunch of indexing reqs

[12:14:43] <aclark> Which I'll paste in here but probably add issues in GitHub too today:

[12:15:12] <aclark> Indexes for: (a) completion state of task; (b) query for tasks with notification meant for specific window/range of two datetime arguments

[12:15:34] <aclark> 2015-07-20 21:17:37suptonIndex/query requirement 1: method gets all tasks not marked as complete with notification date between (datetime1, datetime2) (inclusive)... method performing query could return catalog brains or actual content objects in list, I don't care.

[12:15:44] <aclark> 2015-07-20 21:20:03suptonindex/query requirement 2: "overdue tasks" method queries all tasks not marked as complete, with due date before (datetime1).

[12:15:51] <aclark> 2015-07-20 21:23:34suptonindex requirement 3: "my tasks or tasks for a specific party specified" -- query for all tasks, sorted in chronological order, that belong to an assigned principal (by user name), optionally excluding (or limiting to) tasks already marked as complete. Use case: page lists user's tasks broken down by "completed", "pending", "overdue" (it may be that sorting results into these

[12:15:53] <aclark> categories need not necessarily perform 3 queries)

[12:16:04] <aclark> 2015-07-20 21:24:13suptonindex requirement 4: "tasks that I assigned to other people" -- similar to above, but for tasks assigned by named project manager (by username) to others.

[12:16:16] <aclark> Hmm, let me clean that up:

[12:16:35] <aclark> requirement 1: method gets all tasks not marked as complete with notification date between (datetime1, datetime2) (inclusive)... method performing query could return catalog brains or actual content objects in list

[12:17:19] <aclark> actually, let me just make tickets

[12:17:23] <aclark> !m aclark

[12:17:23] <pmxbot> you're doing good work, aclark!

[12:18:37] <garbas> :)

[12:28:06] <aclark> garbas: ok i'll probably clean this up further but: https://github.com/upiq/uu.task/issues/39

[12:28:23] <aclark> Here's two additional things he said which don't quite fit the "create 4 indexes" task:

[12:28:50] <aclark> (FWIW, might be overlap)

[12:28:53] <aclark> Indexes for: (a) completion state of task; (b) query for tasks with notification meant for specific window/range of two datetime arguments

[12:29:10] <aclark> And… another requirement: implied path query on all of these -- limit query results to objects within current navigation root object.

[12:29:15] <aclark> so that should cover indexes

[12:29:21] <aclark> I'll take a look at UI today ASAP

[12:32:14] <garbas> aclark: #39 is exactly what i was looking for

[12:32:28] <garbas> perfect.

[12:33:34] <aclark> garbas: coolio, thanks

[12:35:15] <garbas> so for now i have on todo list:

[12:35:32] <garbas> - #39:make sure that indexes meet those requirements

[12:36:02] <garbas> - getters for fields in IAssigmentTask

[12:38:12] <aclark> are you working thurs too or just tomorrow? I think we may be able to do some "final touches" on thurs but I can do that if you are unavail

[12:44:46] <garbas> sure i can make it in the afternoon

[12:47:05] <garbas> starting around this time

[13:27:53] <aclark> K great

[13:28:27] <aclark> garbas: also this blurb FWIW: One thing I just realized: it is likely a good idea that indexes querying for notification times use UTC for indexed value (and query API), regardless of how the due/notification times/rules are stored. I just wanted to pass this assumption along as you work on any issues on github.

[13:28:32] <aclark> (from supton)

[13:52:54] <garbas> aclark: +1 will do tnx for a reminde

[13:52:56] <garbas> r

[14:56:06] <garbas> aclark: should taskplanner look into parent taskplanner as well?

[14:56:20] <aclark> garbas: probably not

[14:56:24] <aclark> garbas: sounds out of scope-ish

[14:56:43] <aclark> i.e. i don't think we'll support nested TPs to start

[14:57:08] <garbas> aclark: it is easy to support it, but i think it will be hard to understand for end user how to use this

[14:57:18] <garbas> except if we show this properly in UI

[14:57:46] <garbas> also then we would have a problem with which field comes from which taskmanager

[14:58:01] <garbas> s/taskmanager/taskplanner

[14:58:16] <aclark> right

[15:00:41] <garbas> aclark: i know it has been said, but i forgot and i cannot find it in closed tickets. which fields are shared between taskplanner and task content type?

[15:11:20] <aclark> garbas: not sure if we have a list but i think it's important that I can change the assigned to and/or PM fields… maybe due date. Is "all of them" unreasonable or unnecessary?

[15:11:53] <garbas> aclark: it is basically playing with interfaces then

[15:12:20] <aclark> garbas: i mean my inclination is to make TP simple and maybe support a single field to start with

[15:12:50] <aclark> solid but simple and set the example as to how we might support more fields in the future

[15:12:53] <aclark> etc

[15:12:58] <garbas> aclark: i'll only share assigned/project_manager ... and then later on you can copy paste between this 2 interfaces

[15:13:16] <garbas> or add new fields

[15:13:36] <aclark> k

[15:16:18] <garbas> aclark: you have in your todo list to create&assign local roles like c.task does?

[15:16:33] <garbas> i guess this is the only functionality we haven't talked yet

[15:18:55] <aclark> garbas: maybe, how would that work aside from roles in GS?

[15:19:47] <garbas> let me look again at how c.task does it

[15:20:24] <aclark> K

[15:28:01] <garbas> aclark: looks like something like they do here https://github.com/collective/collective.task/blob/master/src/collective/task/setuphandlers.py#L15

[15:28:21] <garbas> aclark: i'll give it a close look and then write a ticket about this with questions

[15:28:38] <garbas> this might be still on the todo list for thursday

[15:36:50] <aclark> ok great thanks

[15:36:54] <aclark> yeah, I hate setuphandlers…

[20:15:06] <garbas> aclark: looks like p.a.event make our task behave like events. i will strip out start/end fields and add it to our behavior schema

[20:15:18] <garbas> aclark: i'm also adding our first test :)

[20:15:33] <aclark> garbas: k

[20:53:38] <aclark> w00t (first test)

[21:34:30] <aclark> garbas: oh, please send report(s) too when you get a chance; I need to update supton on hours used tomorrow morning

[21:35:04] <garbas> aclark: will do. i still want to work another 2-3h

[21:35:14] <aclark> cool thanks