[cjp]

An ambitious idea. Some questions immediately spring to mind.

> Task is owned by a Project. Project belongs to a User. User is a member of Domain.

Can Tasks have subtasks? Recursively? To an arbitrary depth?

Can Projects have subprojects? (see above)

I assume since a "User" is just an email address, a group email address would implement a "Group" at the "User" level?

In a company setting, Users (Contractors, Employees) come and go during the life of a Project. What happens to Tasks assigned to a User who leaves the (company|Domain|Project)?

[madospace]

So any task with `Parent-Id` will be a sub-task. If User owns the tasks he can see the subtasks tree also. but if you own the sub task alone, for you it is like a normal task with an out of scope parent.

Recursive tasks works exactly like recursive calendar events.

I have not thought about Sub-Projects, any suggestions?

User-Group - That is interesting, I think it should not change the behaviour based on the Type of email, which is difficult to determine.

When a user leaves do the same thing as email - either purge them all or re assign it to someone else.

[cjp]

> So any task with `Parent-Id` will be a sub-task. If User owns the tasks he can see the subtasks tree also. but if you own the sub task alone, for you it is like a normal task with an out of scope parent.

That should work.

> Recursive tasks works exactly like recursive calendar events.

I'm not sure what a recursive calendar event is. Are you reading "recurring" instead of recursive?

> I have not thought about Sub-Projects, any suggestions?

The same `Parent-Id` solution as subtasks should also work here.

[madospace]

> I'm not sure what a recursive calendar event is. Are you reading "recurring" instead of recursive?

yes! sorry i misunderstood. and now we have solution to both recurring and recursive!

> The same `Parent-Id` solution as subtasks should also work here. Yes, it will - but does it complicate the architecture ?