User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:passwordless_protected_access

This is an old revision of the document!


Passwordless Protected Access

1. Does the user get a snapshot or access to future changes as well.

The current state.

2. What access does the user get when accessing this issue? For
example,
does the user then get access to private notes?

In our current implementation no. But that could be an option I guess. We use private notes for internal conversations we don't want our customers to read.

3. Does the user only have read-only access to the issue?

For us yes, (but they can add notes). We don't want customers all increasing priority to “extremely high”. Sounds like another candidate for some preferences for the Mantis admin to choose.

4. What configuration options are going to be used to implement this
feature?

I need to read some more Mantis code to see how this works.

5. What are the suggested database changes?

The main one is that we need a random key assigned to each bug. Then:

http://mantis.company.com.au/task.php?key=987tyjkhcgwip2uy523hriu

will take you directly to the appropriate page. The way we use that is to put that link into outgoing confirmation emails. Customers can click on the link to be taken directly to the appropriate task, see the (public) notes and history and make another note. It is very important (for us) that this page be highly customised. We want only a subset of fields (for instance we don't want them to know who is assigned to the task, or what priority we decide to set it) and we want a page design which looks pretty.

Here is an example which we were using for testing a while back:

http://squish.ish.com.au/t?i=4691&w=qxn0CoSqgIi0NDZ96VSl

Some Ideas

  • At the moment we implement anonymous access by creating a shared account for it, then automatically authenticated users that don't login as this Mantis user. This provides consistency in determining what the users can see and do. This also gives the administrator/managers the ability to decide what an anonymous user can do for each project. We should do the same for this kind of access. Once a user visits a link we authenticate him as this user, but we don't setup any cookies. Hence, if the user navigates to other pages of the installation the user will get access denied. Such kind of authentication is done in scripts like the SOAP interface.
  • In the case where a customer gets a link with the passphrase for a private issue. The customer should get access to the issue even if the account used typically doesn't have access to private issues. So the code that checks access to the issue as a whole will have to keep this into consideration.
  • If a logged in user (i.e. viewer, developer, manager or administrator) clicks on a link that has the passphrase, then the passphrase access should override the default access for this user. Hence, the user can preview what non-registered users will see when they visit the same page.
mantisbt/passwordless_protected_access.1176579471.txt.gz · Last modified: 2008/10/29 04:31 (external edit)

Driven by DokuWiki