Issue 2550791
Created on 2013-01-24 01:39 by retroj, last changed 2017-02-26 03:48 by rouilj.
File name |
Uploaded |
Description |
Edit |
Remove |
provisional_user
|
ThomasAH,
2016-07-04 13:01
|
|
|
|
msg4772 |
Author: [hidden] (retroj) |
Date: 2013-01-24 01:39 |
|
I would like to be able to disallow users from adding and removing names
other than their own from the nosy list.
One way that was suggested to me that this could be done is by adding it
as a feature of nosyreaction.py, disabled by default, but enable-able
through a config.ini setting.
|
msg4775 |
Author: [hidden] (ber) |
Date: 2013-01-24 08:14 |
|
Hi John,
thanks for using roundup and giving us feedback!
For a specific tracker, yes, I believe you can just use an
auditor to implement your behaviour. See the documentation how
to do this.
|
msg4776 |
Author: [hidden] (ThomasAH) |
Date: 2013-01-24 09:00 |
|
I wrote a detector who checks this, but it is for a modified template
which has groups for users and users can add/remove other users that are
in the same group:
http://hg.intevation.org/roundup/fast-decomposed/file/tip/detectors/nosyauditor.py
After simplification this could be added as a sample detector.
|
msg4777 |
Author: [hidden] (retroj) |
Date: 2013-01-24 16:51 |
|
Should this be done as a new detector or as a feature of the existing
nosyreaction detector?
|
msg4778 |
Author: [hidden] (ThomasAH) |
Date: 2013-01-24 17:25 |
|
"nosyreaction" is a reactor script, this feature needs an auditor.
A sample script in the /detectors directory (not in templates/detectors)
should technically be enough.
On the other hand having more features available with just an entry in
the config (e.g. newissuecopy) might be nice, too, but then the file
would be duplicated to many of the template directories.
|
msg5707 |
Author: [hidden] (rouilj) |
Date: 2016-07-02 18:34 |
|
John:
I am going to plan on closing this in a couple of weeks if there is no
update. Currently it doesn't seem to be something we
will be writing or including in the roundup codebase.
If you have a working auditor example though feel free to re-open
attach your solution to the ticket and add the patch keyword.
However, I wonder if for your use case, this could be handled
differently in the web frontend.
You still need the auditor since a user can submit any request to the
tracker. Without the auditor they would be able to delete any user as
a result.
However for your use case does it make sense to always display the
nosy list as a read only field (unless the person is an admin or
manager). Users add themselves to the list using a checkbox (called
'in_nosy_list' for example) that the user can toggle to add/remove
themselves from the nosy list?
I am not quite sure how to set that up at the tracker level except by
hijacking the EditItemAction somehow to allow a new EditItemAction
to run something like (warning py pseudo code ahead):
if 'in_nosy_list' in self.form:
self.db.issue.get(issue, 'nosy')
check the value of self.form['in_nosy_list']
if unchecked remove user from nosylist
else add user to nosylist
self.form.list.append(cgi.MiniFieldStorage(
"nosy", new_nosy_value)
)
# call the original EditItemAction handler somehow
EditItemAction.handle(self)
It's possible somebody else on the mailing list or this issue can figure
out how to do this and supply a recipe.
Also it seems like this could be something we could add to
EditItemAction triggered by a special name for the checkbox. E.G.
a checkbox named:
@modify@nosy:add_remove
will add (if checked) or remove (if unchecked) the current user from
the nosy list.
I am not sure if Thomas or Bern have other ideas on this but...
It would be nice to be able to pass these form fields into the
detectors somehow without requiring a database field to back the field.
-- rouilj
|
msg5738 |
Author: [hidden] (ThomasAH) |
Date: 2016-07-04 13:01 |
|
And for completeness, a patch I created for an older roundup version
(last tested with 1.4.9), which creates a "Provisional User" role and
implements the feature requested here and some other things.
|
msg5935 |
Author: [hidden] (rouilj) |
Date: 2017-02-26 03:48 |
|
Thomas, you may want to put a link to this issue and the patch on
the wiki. I don't think we should add this functionality to the existing
tracker templates.
Closing. -- rouilj
|
|
Date |
User |
Action |
Args |
2017-02-26 03:48:47 | rouilj | set | status: open -> closed resolution: remind -> later messages:
+ msg5935 |
2016-07-06 02:49:10 | rouilj | set | keywords:
+ patch |
2016-07-04 13:01:57 | ThomasAH | set | files:
+ provisional_user messages:
+ msg5738 |
2016-07-02 18:36:36 | rouilj | set | keywords:
- patch |
2016-07-02 18:34:54 | rouilj | set | status: new -> open resolution: remind messages:
+ msg5707 nosy:
+ rouilj |
2016-06-27 03:42:03 | rouilj | set | keywords:
+ patch |
2013-01-24 17:25:55 | ThomasAH | set | messages:
+ msg4778 |
2013-01-24 16:51:31 | retroj | set | messages:
+ msg4777 |
2013-01-24 09:00:01 | ThomasAH | set | messages:
+ msg4776 |
2013-01-24 08:54:20 | ThomasAH | set | nosy:
+ ThomasAH |
2013-01-24 08:14:45 | ber | set | nosy:
+ ber messages:
+ msg4775 |
2013-01-24 01:39:34 | retroj | create | |
|