myWork24 asks two separate questions before it lets you near a project, and you need a yes to both. Can you reach the Projects module at all? — that is your role. May you touch this particular project? — that is your relation to it. A role on its own leaves you looking at an empty list; a relation on its own is unreachable without the role.
Four ways onto a project
Any one of these puts the project in front of you.
- You run it. You are the project's PM. You see it, you contribute to it, and you are the one who grants access to everybody else.
- Your department runs it. The project's owning department is one you belong to, or one you manage up the tree. You see it and you contribute to it — you are the team doing the job.
- You were given access on the project's Access tab, either by name or as part of a department. What you may do is the level that was chosen for you: view, or contribute.
- You may see every project. An oversight role that reads the whole portfolio. It is deliberately read-only and never lets you change anything.
If none of the four is true, the project is simply not in your list. You are not shown a locked project with a padlock on it — you are shown nothing at all, which is why "I can't find the project" and "I'm not allowed into the project" look identical from the outside.
A department grant matches on your own or managed departments. It is not expanded downward into that department's sub-departments, so if you mean the teams underneath as well, add them.
Every way in carries a level
- Can view — read the project: its summary, milestones, tasks, documents and history. You change nothing.
- Can contribute — everything view gives, plus doing the work: writing the summary, editing and completing milestones, adding and linking tasks, capturing sign-off and recording the acceptance test.
The level belongs to the relation, not to you. You can be a reader on one project and an editor on another at the same time, and that is now the ordinary case. Until this change, project access was one company-wide setting: reader on everything, or editor on everything.
A level only ever widens. It chooses which list a grant joins; it can never take away access you already have some other way. Giving a "can view" row to the project's PM does not demote them, and neither does giving one to somebody whose department runs the job.
Granting access: the Access tab
Open a project and go to its Access tab. There are two panels, and they do the same job for different populations.
- People — add somebody by name and choose their level. The row then shows what that person can actually do on this project, which is not always the level you just picked.
- Departments — add a whole department at a level. This is how you give a team access without naming everyone in it, and how that access survives people joining and leaving.
Only the project's PM can grant access — plus an administrator. Being able to contribute to a project does not let you hand it out; that stays with the person accountable for the job.
When "can contribute" still cannot
Somebody can hold a contribute row and still change nothing, because every permission has two halves: the door — your role, which decides whether the Projects module exists for you at all — and the room — your relation to this project. Adding a colleague who holds no Projects role creates a real grant, gives real scope, and does nothing.
The People panel says so on the row, and names what has to be granted. It tells you at the moment you add the person rather than a week later, when they report that the link you sent them does not work.
Seeing a project is not seeing its money
Two things stay separate from everything above and are granted on their own:
- the customer, the sales-order links and the client signer;
- the budget and contract value.
Neither is implied by anything else — not by contribute, not by being the PM, and not by being an administrator. Somebody has to grant them deliberately. So a person can run a project from end to end and never see what it is worth, which is the point rather than an oversight.
The short version
- Two questions: your role opens the module, your relation opens the project.
- Four ways in: you run it, your department runs it, you were given access, or you may see everything.
- Every way in carries a level — can view or can contribute.
- The level is per project. Reader here, editor there.
- Grant it on the Access tab. Only the PM can.
- A contribute row for somebody with no Projects role does nothing — and the panel says so.
- Customer and money are granted separately, to everybody, administrators included.
Working the job itself — milestones, tasks, documents and sign-off — is covered in Running a container BESS project.