I'm new to ClockingIT so I might be missing something already possible. What we need is the ability to add both companies and people. At the moment we have clients, who look a bit like people (since they have an email address) but are also a lot like companies (since they are joined to a project).
We'd like to have both. Grouping people into companies would allow us to designate a project as related to companies A, B and C rather than the 20 people who work there. But also attaching people individually to certain tasks would be useful when thinking about email integration, access rights and tracking individual contributions. It would also allow for more flexible 'add this person' interfaces when dealing with thousands of people/companies in a system.
What would be involved in this kind of structural change or can we fake it somehow now?
You could possibly remove all checks against the users company_id, and make everyone share the same install. It would probably be easier to add support for something like departments, though, as everything is checked against your company_id and you'd have to modify just about every SQL statement there is.
Ah, I see. Your concept of 'company' refers to the shared hosting idea of installation or virtual host. Some approaches might be:
* keep your concept of companies and allow clients to be attached to them (they are now, but not visibly in the GUI), then we'd need a flag which switched CIT from keeping companies completely isolated from each other to sharing data when appropriate.
* add a whole new table (department isn't the right word), maybe client_company. This could then be used in the shared hosting environment which is probably better since it would be more useful to you and your customers.
What do you think about the idea of then moving the project -> client relation and making it project -> client_company. A client_company record would be created automatically for each existing client and there would be a simple way to create both client and client_company in one go. Or else, we could keep the project->client relation as is, make it many-to-many, and have a simple way to add multiple clients in one go. That might be more flexible if you deal with a bigger company on several projects and don't want to involve all staff equally on all projects.
Doing this is a deal breaker for us migrating from our existing system, so we'd be prepared to lend a hand (so far as our limited Ruby skills are concerned). We do have extensive SQL, Java and a fair amount of CSS, Javascript and PHP.
Is there a database schema document anywhere, describing all the relations?
I do have a clients table (called customers due to historical reasons), which I've always intended to hook user accounts up to so that the account belongs to a client and could be filtered and given permissions by editing the client. There's just always been something else more important for me to fix. :-)
I'd love help with ClockingIT, and it doesn't have to be Ruby code. CSS fixes, new designs, better work-flow, re-designs of old pages, translations, documentation, etc. Loads to do even if you're not a ruby expert.
There isn't really any schema document, as Ruby on Rails does the relationships in code, but it's all documented in app/models/*.rb. I have seen a system for generating a graph of your schema a while ago, but I can't for the life of me remember what it was called.
