Brilliant! Look forward to seeing it.

Max, Any progress on this? I was thinking of porting tracks Salt Login Generator as a first step to MUF.

I've some development along this track. I've svk mirrored the tracks trunk and branched it here https://guest:guest@svn.plumtree.co.nz/repos/tracks/local/shlg-tracks/ for my development tree.

The code here is about 80% along the way to allowing multi-user unsharable lists on one server. Check doc/notes-sql for adding the correct DB entries.

Should be usable and needs some testing.

I've installed the svn version above. Has this been merged into the main tree yet, or do I need to diff and start moving it in?

This is ready for alpha testing now. r190 from my subversion repository above is in good order except for one minor thing. People will at this stage need to manually update their schema. Check out db/migrate/2_add_user_id.rb and db/migrate/3_created_at.rb.

The one issue remaining is uniqueness of context and project names. I'm need to investigate if its possible to scope/restrict the validation tests. Otherwise, everything else should would.

Note at this stage only the first user (admin) can add users. Plus there is no user management. bsag said she'd work some nice interface for this. ;)

Once it a couple other people have given this a test I'm sure we can start looking at a quick sync then merge back to bsag's tree.

Note if you are testing this, I've modified my rails so I can specify NOT NULL in the migration scripts. This depends on http://dev.rubyonrails.org/ticket/1712.

I'll probably change this for the final release so its specified manually. Since its unlikely this patch will be in rails soon.

Finally r190 definitely depends on Rails 0.13.1.

Good to hear Nic! I need to contact you via e-mail, but I'm (hopefully) going to be contributing at least some to your multi-user efforts. I was hoping to get support for an LDAP backend to Tracks working (optional, of course), as well as basic delegation functions. :)

If I get the latest svn on this, then I'll have 3 working installs of Tracks on my development box. Eep! Gotta merge these source trees soon.

Numbski, you can email me at emptysands@gmail.com. Note I've now committed most of my changes to http://dev.rousette.org.uk/browser/branches/tracks-mu-import/. If you have any patchs please "svn diff" against that.

If you have a major change I might be worth leaving it until next release. I'd really like to get the current functionality readily for general beta testing. If you have some seperation functionality for delegation, it might pay to open another ticket for that.

Note, my next step is to finalise moving to salted hash login generator or similar to make self-signups possible. Currently user's have to be created by the admin user. My goal to this point has been just to get MU working, plus I got side-tracked tidying up the rendering.

Just a head's up.

Tony Shadwick == Numbski

Which means of course, that OSS Solutions is a go, and will be lending a hand on this project. :)

I'll drop you an e-mail in a bit Nic.

I notice this is still open. Any update? I'd likely take a stab at this but curious what the status of the existing set of patches is.

Stage one is done. Start of the next stage with better user management tools is waiting for the next rails release. However I think the next release focus is going to be on improving the UI.

is this still under development?

I don't understand about this feature at all.

Tracks 1.5 does support multi-user. But, it doesn't support new user to signup to use Tracks. It supports multi-user in another way where admin should add the account manually.

So, this ticket actually wants to create a MU feature that any new visitor can sign up for a new account to use?

Looking at the ticket number, this ticket was meant for the initial development of multi-user capability. I'm not sure if this ticket should remain open or that we can close it. Your enhancement suggestion is not part of this ticket AFAICS, so you can consider to add it as a separate enhancement request.

Updating tickets (#743, #752, #768, #781, #535, #47, #295, #298, #805, #806, #324, #584, #97, #592, #344, #603, #114, #629, #636, #645, #393, #405, #433, #434, #202, #462, #220, #233, #310, #95, #635, #397, #94)

Updating tickets (#17, #47, #49, #83, #91, #97, #103, #107, #117, #125, #126, #175, #177, #183, #188, #197, #206, #211, #236, #240, #276, #294, #295, #305, #309, #312, #317, #324, #355, #357, #358, #371, #373, #393, #434, #452, #478, #503, #507, #535, #564, #565, #568, #569, #571, #572, #636, #668, #682, #686, #692, #715, #736, #741, #759, #773, #782, #783, #800, #828, #837)

I had thought about this multi-user desire that has been hanging around for so long.

What if we did it in a distributed manner kind of like a calendar invite. When you wanted to share or assign a todo to a different user (whether on your tracks server or even on an entirely different one), a restful PUT message is used to send the todo. On the receiving end, the received todos would visible in a container where the user could accept, reject or ignore it. If they accepted the todo, then a response message would go back to the sender and the sender's copy of the todo would be updated to reflect it. If the todo was completed, then this could be communicated as well.

We'd need to leverage some sort of token exchange to support the messaging. This route feels like it would get around the issue of controlling access across users for a single todo since there would really be two separate, but related todos.

Maybe my idea has already been floated, but I thought I should throw it out there and see what people think.

That is a good idea to incorporate into current tracks.