Based on this discussion I have now re-introduced the "authenticated" user
group and given it the following permissions:  TICKET_CREATE,
TICKET_EDIT_DESCRIPTION, TICKET_MODIFY, WIKI_MODIFY

I have also tested it successfully. Every registered user can now create,
edit and comment on tickets, and also modify wiki pages once he/she is
verified.

I did come across what I would consider an error though: Registered users
that haven't yet validated their email address get shown the quick ticket
dialogue, which does not complain about their permissions. However once the
ticket is submitted it returns an "Internal server error", instead of the
usual confirmation that the ticket has been raised.

In my opinion we should either show a clear message up front along the
lines of: "You need to validate your email address before you can create
tickets. [resend validation email]" or queue up created tickets to only be
inserted once the email address has been validated.

I think we should also move the registration link out of the Apps dropdown
(renamed 'More' in my next commit) and into the metanav:
[Login] / [Register]    [Preferences]    [Help/Guide]

Cheers,
Joe


On 17 April 2013 06:38, Alexander Heusingfeld <[email protected]>wrote:

> Hi all,
>
> generally I agree 100% to Gary's arguments.
>
> To give you another use case:
> Requiring only the authors email for ticket creation comes in very handy
> especially for tool support: Think of a "Report this bug" button! In case
> of an error it shows up, the user presses it, enters his email in a popup
> and click submit.
> That's very convenient for the user and the software author gets much more
> feedback! A similar approach is currently used in IntelliJ IDEA.
>
> Cheers
> Alex
>
> On 17.04.2013, at 07:22, Branko Čibej <[email protected]> wrote:
>
> > On 16.04.2013 23:30, Andrej Golcov wrote:
> >> I think that the user registration provides better long-term relation
> >> between user and site than an e-mail entry on comment or ticket. For
> >> example, the problem that I see with t.e.o:
> >> - e-mail changing is not possible for submitted comments
> >> - if comment was submitted with email, the user cannot edit it.
> >>
> >> Supporting both ways is also, IMO, is not good: imagine that user once
> >> sent a feedback with email and another time as registered user -
> >> things can be confusing.
> >>
> >> So, my 2 cents to require user registration, but make it simple and
> >> clear (may be with support of openid or/and google accounts) and with
> >> subsequent redirect to the original url e.g. ticket creation url.
> >
> > Frankly, I don't think it'll work. I'd prefer requiring registration
> > before allowing people to create tickets; but most reporters just won't
> > bother. It's the same as mailing lists: if we allowed only posts from
> > subscribed addresses, we'd never get any feedback.
> >
> > -- Brane
> >
> > --
> > Branko Čibej
> > Director of Subversion | WANdisco | www.wandisco.com
> >
>



-- 
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>

@jdreimann <https://twitter.com/jdreimann>
*
*
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
 If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone.  Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized.  The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf.  All email
sent to or from this address is subject to electronic storage and review by
WANdisco.  Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.

Reply via email to