We’ve put the ‘All’ project readonly for everybody except a few people, because new users were wrongly adding tickets to this ‘All’ project instead of the correct one. After this permissions issue was changed, things are working much better.

I also think that this dashboard idea, news feed, etc., looks very interesting.

It sounds to me like every page in the portal is required to belong to some project. If this is true, it would seem probable that it’s a remnant from Trac, where the only purpose for the portal was a singular project, so anyone with an account naturally belonged to that project, and all is well with the world.

With DrProject, it sounds to me like users should be able to have an account with the *site*, and so there should be a ‘user’ table with nothing much in it but account id’s, passwords, names, and perhaps email addresses (if you only allow one email address, anyway). That gives you a one-stop place for contacting everyone associated with the entire *site*.

The notion of a project, then, is different. There should be a project table that contains *only* the bits of data that describe that entity, like the name and description of the project, a project id, perhaps the user ID of the *owner* of the project, and that’s probably about it. The important bit here is that there should be only one row per project in this proposed table.

To map user IDs to projects, there should be a mapping table that contains two columns: a user ID column, and a project ID column. There should probably be a unique index on this table made up of the two columns combined, to insure one user can’t belong to the same project twice, and you can optionally throw in an autoincrement ID field in the table if you’re just used to using them (it’s not necessary, and isn’t likely to do much to help your application).

So now you have a method by which you can not only email everyone with an account on the site, but also email anyone associated with just a particular project, or a particular collection of projects (and sql for removing duplicate users from a query against multiple projects is trivial).

When people log in, they should probably just be presented with a list of projects they belong to, along with maybe some links to edit their account information, and to join/browse other projects.

The highest level in the navigational hierarchy is not a project. Forcefeeding this to the users is likely to be confusing, as you’ve learned. There *should*, however, be a “site” project where people can go to log problems with the site itself, but it’s not clear to me that someone would need to belong to that project to do so — they just have to have an account on the site.

A long rambling comment about a project I admittedly don’t have any experience with, but I hope something useful comes of it anyway

Also, a little usability problem that I ran into several times: when I log in, sometimes I would put my username and password and then select my project before hitting submit. Of course, changing the project combo box would cause the page to reload, wiping out my username and password.

I think you should either make it more clear that project selection has nothing to do with logging in, or else have the combo box submit the login form when it reloads the page.