The task management site Dozilla.io offers different levels of access control to a project and its tasks:

Access link

The unique link to a project (which can contain one or more lists) is the first level of access control: Only people who know this link can access the project. They can read all tasks within the project, add, edit and delete tasks, move lists etc.

https://dozilla.io/todo/index.php?pid=verylongstringwithrandomcharacters

When you share a project or a task via the share icon , you effectively tell someone this unique link. So it is important to keep this link private to the group of users which should access the project.

Protecting or freezing lists

When you are an administrator (see below), you can freeze or protect a list with a password in the list menu:

This lets you define a password which needs to be entered by people who want to access the tasks of this list. Note that the password is valid on list level, so other lists within the same project may still remain open.

Protected lists will not be exported. Once the user enters the correct password, the list will remain open for him for the remainder of his browser session (i.e. until he navigates away from Dozilla.io).

You can also set a list to “private”:

This means that standard users (wo are allowed to access the project) can see only their own entries, i.e. tasks which they created or updated themselves (on that device). Only administrators can see all tasks.

Tasks of such “private” lists will also not appear in the “All”-list or in a PDF export.

Use this functionality to have lists where user can add entries independently (and secretly) from each other, e.g. for a Christmas wish list for your kids (with one list per kid who can fill that list, and only you as administrator can see entries from all lists), or for a brainstorming session where each colleague or small team fills their own list and only at the end you as administrator change the status back to “non-private”, or similar… To make this even more secure, you could also protect each list with a different password…

Note that setting a list to “private” which already contains several entries is risky; an entry will be visible to whoever updated it last! It’s better to create a fresh (empty) list, set it to “private” and then let users enter tasks.

Working with user roles and project stati

The third and most powerful function for controlling access to a project is the definition of user roles – in conjunction with the project status.

By default, the creator of a new project receives the role “Administrator” (in fact called “Creator”, which is identical), and everyone else who accesses a project receives the role “Standard”.

Standard users can work normally on a project (depending on the project status – see below):

• Access open projects
• Read, create, update, delete tasks in
• Check a task (i.e. mark as complete/incomplete)
• Create and delete lists
• Add comments to tasks and to chat
• Move or copy tasks
• etc

Administrators by default can access their projects and have additional functionality (compared to standard users), which is:

• changing other users’ roles
• password-protecting a list
• locking a list
• setting/unsetting a list to private
• deleting comments on tasks or in the chat
• clearing or deleting a survey (in the chat)
• deleting the entire project

Go to the security / access settings in the project menu to see the current project status, the project users and their roles:

Project status

There is a screen which shows the project status and all users who have accessed this project, with their role:

The project status determines the type of access. It can be:

Open (Knowing the link suffices): Everyone can access this project (read and write) who knows the link to it. This means that you only need to share the project link (via the icon) to someone. As soon as this person opens the link, he/she can access the project: read tasks, create tasks, edit tasks, delete tasks, etc – see “Standard user” above.

Access right needed: Everyone can access this project (read and write) who knows the link and who has at least the role “Access approved”. This means that you need to share the link and additionally you need to enable the user to actually get access: Set his/her role to “Access approved” in the user list (see below). There is no distinction between read access (i.e. reading tasks) and write access (i.e. creating, modifying, deleting tasks etc) – this is both possible with role “Access approved”.

Read/write-role needed: Everyone can access this project (read only) who knows the link. To create, edit, delete tasks, the user needs at least the role “Approved (write)”. This means that you need to share the link and additionally assign the user the role “Access approved” for read access (so he/she can read tasks, but not edit them, create new tasks etc) or the role “Approved (write)” for write access (i.e. creating, modifying, deleting, checking tasks etc).

Read with link / write with role: Everyone can access readonly this project who knows the link to it (and can vote for a task). To create, edit, delete tasks, the user needs additionally at least the role “Approved (write)”. This setup is useful when you have a “public” list which everyone who knows the link (which you maybe have publicly distributed as QR code or similar) can access, but only a few “editors” shall be able to add new tasks, edit them etc – for example let people vote for their favourite song in a playlist that you as DJ shall play next, or maintain a feature backlog such as my backlog for this site or whatever…

Administrators can always access, read and write in a project (independent of the project status), and they can additionally assign roles to users, delete projects etc

If a user accesses the project (because he/she knows the link) and the role is not sufficient (e.g. default “Standard” but requires “Access approved”, he/will be automatically set to role “Waiting” so you know that this user is waiting for a role upgrade.

Independent from the project status, you can still set a list to locked, frozen or private (see above).

User roles

On the same screen, you see the list of users.

By default, all projects are “open” upon creation, meaning that anyone who knows its unique access link can see, edit, delete the tasks, and thus the default role for users is “Standard”.

The roles become more important when you switch the project to a different status. When you switch the project e.g. to “Access right needed“, only users with roles “Access approved” or “Admin” can access it. The user list marks those users with green icons (marking read, write and admin functionality) who can access the project.

As stated above: If someone tries to access the project without sufficient rights, he will see an error message. You can easily test this with a browser in incognito mode.

In the access control list, this user will be marked as “Waiting”. Click on the little user image to learn more about that user. To grant access for this user, change the new role to “Access approved”: Choose the new role in the dropdown box on the right and click on the “Update” button.

Then the user can access the project. To revoke access of a user, similarly set the status to “Standard”.

As stated above, depending on the project status you may need to set a user to “Approved (write)” in order to enable him/her for creating, editing, completing, deleting tasks etc.

This screen also allows you (as administrator) to delete a user: set the dropdown box to “Delete”. The project link will be removed from his machine ID (see below). Note that this cannot prevent anyone to open the link again if he stored it somewhere; then the user will reappear in the list as “Standard” user. Be also VERY CAREFUL when removing administrators altogether, or even only reducing their role – you may end up in a situation where there is no administrator left in the project, so noone can change roles anymore! That is the reason why you cannot change your own role.

By the way, you can see the allowed functions of yourself with the little icons at the bottom of the tasks screen:

Click on the image to change it.

Some words on identification

The overall idea of Dozilla.io is based on simplicity and anonymity – that’s why there is no registration process with email, password etc. However, it is needed to identify a user (or better: a device) uniquely to control access, distinguish between own and foreign projects, tasks etc.

This is done by using a “machine ID” – a long, random string of characters which is placed on the user’s device in a cookie. You can check your machine ID in the debug information, reachable via and then .

Keep this machine ID private – this is your master key to your projects! This also means that you should not delete the respective cookie (called ‘mid’), because then you will loose access to your projects.

If you yourself use several devices, read this article.

For safety reasons you can export the relevant information to a backup; go to the top level main menu (on the list of projects screen) and click on “ Migrate projects”.

API and email access

Note that the “Machine ID” restrictions (and project stati restrictions) do NOT apply for API access and email access, as in those cases access originates from unknown devices. Instead, protection is achieved with a unique API token resp email address. In the Info menu of a project you can protect these access methods, specifically if you switched your project from “open” to a more restrictive status and you are unsure if a previous user noted the current API access token or recipient email address:

• Create a new API access token to protect the API access.
• Create a new recipient email address to protect the email access.