No 'register' link (only Login), 'New Ticket' -> 'login' difficult

[digulla@…]

I'm really irritated that most trac sites (including this one) doesn't offer a registration link (only Login).

This leads to some frustrating situations:

I come along, want to report a bug. Trac tells me, I need "CREATE_TICKET" permissions. Why do you show "New Ticket" if I can't??

Now, I try to find a way to register. But there isn't.

Next, i try to find some other way to post my bug report but there isn't.

I give up.

I suggest that you disable the links to the ticket system when anonymous posting is disabled plus put a big warning next to the option for the site admin.

[mgood]

Login on this site is only for the core developers. Anonymous users have the standard permissions, so there's no need to register here.

The "New Ticket" button is disabled if you don't have TICKET_CREATE permissions on a site. If you can provide a working example of the problem mentioned above go ahead and open a ticket with the relevant information.

You can allow users to register on a site using the AccountManagerPlugin. If you encounter a site that you feel needs registration, please contact its administrator.

[anonymous]

There are two situation:

1) anonymous ticket opening is allowed 2) you must be logged in to open a ticket.

This is fine.

If the admin chooses option 2, to prevent spam say, then here is a scenario that happens commonly:

1) a user finds a bug 2) the user goes to the project web site which is hosted with Trac 3) the user looks for the "New Ticket" button, and licks it

(note here that the ticket *must* be present whether the user is logged in or not)

At this point there are two possibilities:

a) the user is already logged in. In this case, they can proceed to create the ticket b) the user is not logged in.

Case b is not handled well currently. At this point the user should be notified that they must create an account before they can create ticket. The form for email address and password should be presented. And then they should be redirected back to the New Ticket screen, in a logged-in state, so that they can create the ticket as in step 'a' above.

This is exactly analogous to browsing Amazon, clicking to put something in the shopping basket, and then being prompted to login. If Amazon hid the 'add to basket' button if you were not already logged in, or lost your item when forcing you on a detour through the login process, they would not be as successful as they are. Software projects using Trac are not as successful as they could be interacting with users.

Here is an example of an experienced developer stumbling over this UI problem:

http://thomas.apestaart.org/log/?p=644

Please consider handling this common scenario in the otherwise handy Trac software.

Thanks.

[nkantrowitz]

As mentioned above, Trac does not offer user registration. If you have suggestions to improve the registration process, please submit them on the accountmanager plugin.

As for the "don't hide UI elements" issue, this gets very difficult to configure. Obviously not all menu elements should be shown to all users (eg. Admin), but I agree it is nice on some projects to continue to show the New Ticket link even without TICKET_CREATE permissions. This is probably something that is worth including as a sample plugin. What do others think?

PS: In the future please do not reopen unrelated tickets for new issues.

[anonymous]

Regarding hiding UI elements, perhaps they should be treated in the same way that menu items are in a traditional desktop application: grey out the disabled items. The reason is that you are trying to communicate something, "you can't do that", for example. But you can't do that by completely removing the element. What this often communicates is "you are stupid and can't find the New Ticket button", sadly.

How about this:

1) anonymous user views Trac page, not logged in. Only logged in users can create tickets. The New Ticket button is displayed as normal, but the tool tip says "Log in and create New Ticket".

2) logged in user views Trac page. Only logged in users can create new Tickets, they have the appropriate privilege. Tool tip says "Create New Ticket".

3) logged in user views Trac page. Only some subset of known users can create new tickets, and this user does not have that privilege. The New Ticket button is shown but in a greyed-out state. The tootl tip says "You are not allowed to create a New Ticket".

This seems like a change that would have to be made to Trac itself.

The other question is what happens in step 1 above when an anonymous user clicks on the New Ticket button. Are the necessary hooks available so that an auth plugin can capture the 'unauthorized' error, do the login, and then return the user to the right page in the logged in state? If the buttons could remain visible and the hooks are available, then it looks like we could move on to clean up any auth plugin problems.

btw. here is another recent example of an experienced developer having trouble negotiation the New Ticket / "TICKET_CREATE privileges are required to perform this operation” problem:

http://www.murrayc.com/blog/permalink/2008/06/17/trying-to-file-bugs-for-fedora-linux

[nkantrowitz]

Replying to anonymous:

The other question is what happens in step 1 above when an anonymous user clicks on the New Ticket button. Are the necessary hooks available so that an auth plugin can capture the 'unauthorized' error, do the login, and then return the user to the right page in the logged in state? If the buttons could remain visible and the hooks are available, then it looks like we could move on to clean up any auth plugin problems.

Yes the PermRedirect plugin already exists.

The question is how to balance disclosure with simplicity. With tickets it doesn't much matter, but displaying the nav links for custom internal stuff might cause problems.

I think the initial assumption might need to be what changes. The spambots that hit Trac seem to know how to register accounts, so requiring token logins is probably no longer a good idea. There is a very effective SpamFilter plugin, certainly no more than a few submissions a month get through on here. If you want the semantics of "any user can show up and report tickets", you want to allow anonymous submission.

[anonymous]

Yes the PermRedirect? plugin already exists.

Great! That solves the "TICKET_CREATE privileges are required to perform this operation”. (I'll recommend that fedora use it)

But only if the user can find a link to New Ticket. Just to be clear, are you saying that as things stand now there is no way to make New Ticket (etc.) visible to non-logged-in users without also allowing anonymous users to post; no config setting, no plugin?

(The fedora account system is actually quite convoluted, I'm not sure how many bots manage it)

I hear what you're saying about permissions and UI elements. The mechanism that's used to show New Ticket and Edit This Page is also used to show navigation links which you might want to keep secret until the user logs in. Still, although this is a small UI problem, it has a major effect on usability and it would be nice to have some way to show UI elements to logged in and non-logged in users alike and still force a login on the new screen.

Thanks for looking at this.

[anonymous]

Personally I solve this by having a trigger on my user database which creates an account in the TRAC db when the user is created. Not everyone uses the TRAC system, but it solves a lot of issues when I combine this trigger with the Apache auth_mysql plugin... One username/password for both main site and TRAC for reporting bugs.

Oh... and I also have a great big bold piece of text on the main wiki page telling users how to log in and create a ticket.

[nkantrowitz]

Replying to anonymous:

Yes the PermRedirect? plugin already exists.

Great! That solves the "TICKET_CREATE privileges are required to perform this operation”. (I'll recommend that fedora use it) But only if the user can find a link to New Ticket. Just to be clear, are you saying that as things stand now there is no way to make New Ticket (etc.) visible to non-logged-in users without also allowing anonymous users to post; no config setting, no p

Its a pretty tiny plugin

from trac.core import *
from trac.web.chrome import INavigationContributor

from genshi.builder import tag

class NonauthTicketLink(Component):
    implement(INavigationContributor)

    def get_navigation_items(req):
        if 'TICKET_CREATE' not in req.perm:
            yield 'mainnav', 'newticket', tag.a(_('New Ticket'), href=req.href.newticket(), accesskey=7, style='color: #ccc'))

(note, the above is not tested at all, but should get you started)

The issue isn't doing it, it is what should be the default and how do we make this flexible without having way too many options. Adding a .always_show option to the [mainnav] and [metanav] section might be a decent option. You would then just add something like

[mainnav]
newticket.always_show = true

[rblank]

Interesting ideas in comment:8.