As a result, I’m removing the messages section although this may cause cofusion with users unfamiliar with the term “tickets” so I may leave the messages tab in explaining the decision to leave it out, or just point to the tickets section.

+----+------------+---------+------------+-----------------+----------------------+
| id | account_id | user_id | project_id | title           | SUBSTR(body, 1, 20)  |
+----+------------+---------+------------+-----------------+----------------------+
|  1 |          1 |       1 |          1 | Damians message | Should only be visib |
|  2 |          2 |       2 |          2 | Roms message    | Should only be visib |
|  3 |          1 |       1 |          3 | Branding Info   | A message in a share |
+----+------------+---------+------------+-----------------+----------------------+

The first message should be visible to the first user, the second message to the second, and then thrid to both. This works fine when viewing just a single project which is a leaf node in the hierachical representation of the project structure, but if viewing a project with one or more sub projects, the message from the sub project should also be displayed.

The contents of the project table is displayed below:

+----+-----+-----+-------------------+------------+-----------+
| id | lft | rgt | name              | company_id | client_id |
+----+-----+-----+-------------------+------------+-----------+
|  1 |   1 |   4 | Account root      |          1 |         0 |
|  2 |   1 |   2 | Account root      |          2 |         0 |
|  3 |   2 |   3 | Alumor rebranding |          1 |         2 |
+----+-----+-----+-------------------+------------+-----------+

Projects 1 and 2 are top level projects which belong to users 1 and 2 respectively. The 3rd project is a project where user 1 is the company and user 2 is the client. This means that user 1 “owns” the project. As a direct consequence of this, the project is positioned in the companies project hierachy and not the clients one.

To understand why this causes a problem, I’ll need to explain the way in which messages are retreived in a project with child projects.

Based on the above schema, we can see that each row in the messages table corresponds to the project it belongs to. So to find all the messages in a leaf project, we just need to do a where clause on this ID. If we have multiple projects, we need to look for messages in a range of project IDs, which can be done using a where in clause. This itself would be easy and would work, but we only want to search projects which are sub projects of the current one.

Given the project we’re in now, we can get the left and right values for the project. Any node with a left value between these 2 must be a child of that node, as thats the key principle MPTT works on. In order to limit it to projects in this account, we need to also add a where clause to check the account ID is the same as our account ID.

This works fine for the company account, so if user 1 views the messages sectiion when he’s in the top level account, he see’s the message in the sub project as expected. If we then do the same on the client side, we don’t get the message in the child project (but we do when we view messages in that project). This is because we use the clients account ID as the where clause, and the nested project doesn’t match the clients hierachy.

An easy way to fix this would be to get the companies ID and use that in the where clause. The problem with this is, the company may have other nested projects in that hierachy that the client shouldn’t be seeing. A way around this would be to get the nested hierachy based on the company ID and then do an intersection of the projects IDs with the clients projects

Update

This successfully resolved the problem (but I need to do some checks once I have a more complicated project hierachy to make sure there are no nasty suprises).

However this led to the realisation of another (more serious?) problem. As the project is stored in the companies hierachy, when in the client mode, and in the top level project, it’s classed as a leaf node, as it’s left and right vales are one apart.

In order to resolve this, I’ll have to get all the projects a user is one, get all the projects below the given project in the companies project hierachy, and then intersect the results to get the projets the client should actually see, but I’ll save that for another entry.

Update 2

It turns out this isn’t actually a problem. Only the company needs to see the account in relation to the hierachy, the client just needs to see the problem as is. So all I need too do, is determine if the user is in the company or client account on the project, and if they’re in the client account, just show messages relevant to that project, and if they’re in the company account, we need to check the project hierachy. The only special case for the client is for the account root project, which can easily be identified as it has a left node value of 1. In this case, we just pull back all the users projects.

The messages section acts as a centralised repository for all the messages sent during the project. By no longer having them scattered through countless email accounts spread across different users email systems, we can ensure all users know what’s going on, as everyone has the same information available to them. It will also be possible to send messages within the company on a project (just like you could send an internal email to your company) but the default is to be as open as possible.

Standard options such as sorting messages into categories will be available, and you can reply to a message just like you would with an email. A basic WYSIWYG editor will also be available, but will be heavily stripped so as to not take away too much from the content.