164713 - create observer account bit

Status: RESOLVED WONTFIX

(Bugzilla :: User Accounts, enhancement)

Description

[timeless]

we're starting to use mailinglists for accounts in bugzilla (networking and
layout qa want them, bugzilla reviewers want them, other people will certainly
have uses for them).

in fact we've had two observer accounts for ages: [e-mail] and
[e-mail]

the problem with observer accounts asis is that people can login as them and
make changes (including asking for a new password and changing the password)

so how should this be implemented?
there should be an account bit [x] observer, which can be set on an account, but
only removed by admins (or delegates, but that's a detail i don't have to worry
about).

subject to a bit of discussion before we implement it, but i think this is a
good set of lists of allowed/disallowed options once the flag is set:

allowed:
* queries (relatively useless, but there's no harm in prohibiting it)
* changing email options (http://bugzilla.mozilla.org/userprefs.cgi?tab=email)

unavailable:
* asking for or changing the password
* creating/changing bugs, attachments, saved queries, permissions, email
address/pretty name
* http://bugzilla.mozilla.org/userprefs.cgi?tab=footer (arguably totally useless
and thereby worth ignoring)

open questions:
* does the flag have to be set at account creation or should it be settable from
preferences.

When logged in using an observer account, the footer should indicate that it's
an observer account.

note that observer accounts are used both here at bmo and in issuezilla
installations, they serve a different purpose than multiple assignees.
An observer list allows zero or more people to track bugs and for people to
search based on the interests of that group. the people who follow an observer
list may change at any time (either by unsubscribing from the mailing list or by
removing the observer from their watches list).

Comment 1

[Joel Peshkin]

Should this be a bit or a permission based on membership in a group??

Comment 2

[Myk Melez [:myk] [@mykmelez]]

At b.m.o, observer accounts aren't generally logged into, they just receive
email.  For this purpose no special treatment is necessary, since no one needs
to log into the account on a regular basis.  Is it different at issuezilla
installations?

Comment 3

[timeless]

well err. nobody has occasionally perpetrated comments and mass changes in bmo.
and the concern in mostly that someone who can read a list will ask for the
password (which then goes to the list), read the password, change it, make some
anonymous bugzilla changes and then move along.

Comment 4

[Bradley Baetz (:bbaetz)]

Thats true for the list stuff. You could just add disabledtext to the account,
since those still get mail ATM...

Comment 5

[Gervase Markham [:gerv]]

Yes - I've recently been in conversation with a guy who wanted to use lists, 
and we decided the best current method is to set up the list with an account, 
and then disable it. (This should be documented somewhere.)

However, I'd probably consider it a bug that users whose accounts are disabled 
still recieve email. (Obviously, if we fix this, we'd need to provide a method 
of achieving the current behaviour.) What do others think?

This is a reasonable way of handling lists, but it means people who are on the 
list and also e.g. the bug reporter get two mails. The only way around this is 
for Bugzilla to maintain the lists - but that would involve attaching mailing 
list software to Bugzilla in some way. Is there a Perl module for managing 
lists? Or a mailing list manager with a "get the people on list X" interface?

Gerv

Comment 6

[Bradley Baetz (:bbaetz)]

gerv: tehre is a separate bug on that, but w could easily split up the 'send
mail' and the 'can't log in' bits - ie disabled people get mail, and move
data/nomail into the db, setting from both userprefs and editusers.

Comment 7

[timeless]

bbaetz: two flag bits sounds fine with me.

duplicate mailings is already a problem (esp from [e-mail]), the
only way i can think of handling it is to add a "don't mail me if you mail
<foo>" option. -- The opposite of watching.  But that's beyond the scope of this
bug.

Comment 8

[Gervase Markham [:gerv]]

> gerv: tehre is a separate bug on that, but w could easily split up the 'send
> mail' and the 'can't log in' bits - ie disabled people get mail, and move
> data/nomail into the db, setting from both userprefs and editusers.

They are split already. The "don't send mail" bit is called the "email prefs
table", and the "can't log in" bit is called "a non-empty disabledtext". 

Does data/nomail still work? I thought we hadn't had that for ages.

Gerv

Comment 9

[Matthew Tuck [:CodeMachine]]

This has all been discussed before somewhere, see also bug #100953.  Suggest
this gets closed out as I don't think there's anything new here.

Comment 10

[Frédéric Buclin]

(In reply to Matthew Tuck [:CodeMachine] from comment #9)
> This has all been discussed before somewhere, see also bug #100953.  Suggest
> this gets closed out as I don't think there's anything new here.

I agree. Wontfix!