myWork24 asks two separate questions before it lets you near a project. May you touch this particular project? — that is your relation to it. Can you reach the Projects module at all? — that is your role. If the project names you — you run it, or its PM added you by name — that relation is enough on its own and you need no role. Every other way in goes through your department or an oversight role, and those need a Projects role as well.
Five ways onto a project
Any one of these puts the project in front of you. The first two name you, and work on their own. The others reach people nobody picked one by one, so they also need a Projects role.
- 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. No role needed.
- You were added by name on the project's Access tab, in the People panel. What you may do is the level that was chosen for you: view, or contribute. No role needed.
- 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. Needs the Projects - User role.
- Your department was added on the Access tab, in the Departments panel, at view or contribute. Needs the Projects - User role.
- You may see every project. An oversight role that reads the whole portfolio. It is deliberately read-only: you can change a project only where you were also added by name.
If none of them is true, the project is simply not open to you. 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, uploading and organising the documents, 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.
The project's documents follow the same levels. Anyone who can view the project can open and download its documents and read its notes. Anyone who can contribute can also upload files and new versions, make folders, write notes, rename and move things, and use the project's Trash: it is the team's Trash, so contributors restore what any of them moved there, and viewers don't see it. Only the PM (or an administrator) can delete all of the documents at once. Whoever you are, the top folder and each milestone's folder keep their name and place, and a controlled document is changed in EDMS. EDMS's own access settings (Manage Access, View-All, private folders) do not reach a project's documents: this Access tab is the only place that decides who sees them.
Seeing the tasks on a project
A task keeps its own privacy. The person it is assigned to, whoever created or manages it, and the managers above the assignee open it in full, and being on a project does not change that. What the project gives everyone who can see it is a window onto its tasks.
- Every task is a card. On the project's Milestones tab and on each milestone's own page, a task shows its status, who it is assigned to, its due date (red once it is overdue), how long it has been running against its target, and how many of its sub-tasks are done.
- Click a card for the summary. It adds the description, the manager, when the task started and finished, and its latest activity.
- Follow it from there. The star in the summary subscribes you to the task's notification channel, so you hear when it moves. The chat icon opens that channel, and the message icon beside a name starts a chat with that person.
- Open task appears only for the people who may open the task itself. Everyone else sees the summary read-only: a task is always changed on the task, by the people it belongs to.
- A draft stays private. Until its owner publishes it, a task shows only its number. A task created on a milestone that has not started yet shows Held and is released to its assignee when the milestone starts.
- Finished milestones step aside. The Milestones tab opens on the milestones that are still pending or in progress; choose All to see the done and cancelled ones too.
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. A person added here needs no Projects role.
- 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. It reaches only the members who hold the Projects - User role.
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.
Handing a project to someone else
A project has one owner — its PM. When the job moves to somebody else, hand the project over rather than adding them alongside you: the owner is the person who staffs it, cancels it and can hand it on again.
- Who can do it — the project's current owner, or an administrator. Being able to contribute is not enough.
- How — open the project and click Transfer ownership in the buttons under its details, or Transfer beside the PM in the Access tab's People panel. Choose the new owner, decide whether the previous owner stays on the team, add a note if you want one, and confirm.
- The previous owner stays on by default. Keep … on the team (can contribute) is ticked, so they carry on working on the project as a contributor. Untick it and they keep only what their department or a grant gives them; if that is nothing, the project leaves their list and they leave its chat.
- The new owner needs no role to open a project they own. If they were already on the team, they move up to the PM row instead of appearing twice.
- The owning department does not change, so nobody else gains or loses access. If the team running the job has changed too, change the department in Edit details.
Every handover is recorded on the project's Activity tab as Ownership transferred — from whom to whom, whether the previous owner stayed on, and the note — and posted in the project's chat. The new owner joins that chat, and every milestone's chat, before the message arrives, so they hear about it straight away.
What the Projects role is still for
Being named on a project is enough to open it. A colleague you add by name in the People panel needs no role and gets exactly the level you chose. They reach the project from a link, a notification, a task card or the project's chat — without the role there is no project list for them to browse.
The Projects - User role is what gives someone the project list and the menu entry, lets them start a project of their own, and lets their department bring them in. So if you add a whole department, only its members who hold the role get in. To bring in one person who doesn't, add them by name.
The project's chat
A project and each of its milestones have their own chat channel. You can open, follow and post in them exactly when you can see the project — by name, through your department, or through the oversight role. Being able to use projects in general does not open every project's chat: a project you are not on keeps its channels closed to you. If you already follow a channel, you keep it.
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 routes in: being named on the project — you run it, or were added by name — opens it on its own; your department or an oversight role needs a Projects role as well.
- 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.
- One owner. Only the owner or an administrator can hand the project to someone else; the previous owner stays on as a contributor unless you untick it.
- The Projects - User role also gives you the project list and lets you start a project.
- Anyone who can see the project sees its tasks as cards and read-only summaries, and can follow them. Opening a task itself stays with the people it belongs to.
- A project's and its milestones' chat is open to exactly the people who can see the project.
- 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.