Hi Keith,

I'm working on sharing contexts under different users. I made a model
for public/private shared contexts and an invitation mechanism.  But
this functionality is limited as actions made by so to say watching user
can't be yet repushed to the mastercontext. This would require a real
messaging mechanism which goes much further than my invitation code. But
a good point to implement this more generalized. Also sharing of
projects isn't implemented but perhaps could be easily adopted. My
frontend knowledge is very limited so I just have noob rhtm/js. I was
always working with an own version of tracks which has several changes
to the HEAD but not really patch - worthy. I always merged in the
changes of the HEAD which was easy and controlable under svn as the
eclipse/radrails plugin is very mature in history and diff functions.
With the switch to git I'm trying to bring both together now in an own
fork but I'm experiencing the git struggle. :) Hope I don't feel so
stupid alone. As soon as I have got my own fork I will tell you. I would
appreciate to work on this together. :)

Greets
Bernhard

Keith Gaddis schrieb:
> Is anyone actively working on functionality to cover subprojects or 
> multi-user interaction along the lines of delegation and watching 
> someone else's actions/projects?  These are high-priority items for 
> me, and if no one else is working on them, I'd like to take a crack at 
> it, or work with someone to avoid duplication of effort.  I've seen 
> tickets in Trac for these functions, but they don't seem to be updated 
> recently (there's also multiple tickets covering each, so i may be 
> missing the active ticket).
>
> Here are my implementation thoughts:
>
> 1) subprojects:  this can be really simple.  All that really needs to 
> be done is add a 'parent' field to the project model and make some UI 
> updates.  Projects with null parents correspond to top-level projects, 
> which can be thought of as areas of responsibility.  subprojects have 
> another projectid assigned to them for a parent.  hiding a project 
> cascades down the tree, marking it visible flows up the tree.  One of 
> the tickets mentions sub-actions, which i think is kind of a 
> corruption of the metaphor--actions should by definition be discrete 
> pieces of work or steps to be taken, not aggregations of them.
>
> this would also make it really easy to implement conversion of an 
> action to a project, setting the parent id to the original action's 
> project, which is also something I'd really like to see, though its 
> far lower on my priority list.
>
> 2) multi-user functions
> first i'd like to implement 'watches', which would allow one user to 
> view the projects, actions, and notes of another user.  further down 
> the line it could be used to implement notifications and 
> dependencies.  The watch UI would allow a watching user to copy a 
> project definition to his own list of projects, and optionally its 
> child actions/projects.
>
> second step in this would be to allow a user to delegate an action or 
> project to another user.  To do so, it would seem like all you would 
> need to do is reassign the user_id.  As a first go-round it would fit 
> my purposes merely to allow any user to delegate to any other, but it 
> could be implemented in such a way as to allow a delegation to follow 
> a request/accept model.
>
> So now that I've laid out what I'd like to work on, does anyone have 
> any thoughts about it?  Is anyone else working on this or similar 
> functionality, or in a different direction?
>
> Best regards,
>
> Keith
> ------------------------------------------------------------------------
>
> _______________________________________________
> Tracks-discuss mailing list
> [email protected]
> http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
>   



-- 

| Bernhard Baase   <OpenObjectives.com>
| Software Engineer (Dipl.-Inf.)
| Friedelstrasse 31   D-12047 Berlin, Germany
| Phone: +49-3222–1444130   Fax: +49-3222–1444130
| mailto:[email protected]
_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss

Reply via email to