Forum OpenACS Development: Scoping users to a package

The bug-tracker has this quite common problem, where we want to
provide a drop-down of users to pick from to assign bugs to, but we
don't want that list to get too long.

Here's the bug:

http://clients.museatech.net/bug-tracker/bugs/bug?bug%5fnumber=2

For now, I've implemented a very sucky solution, where I include a
call to the acs_permission__permission_p PL/pgSQL function in the
where clause, to check if each and every user in cc_users has write
permission on my bug tracker package. Baaad bad boy!

So what is the good way to solve this problem?

A few suggestions:

1) Have the package instance maintain explicit "membership",
creating some pages to handle this, possibly using acs_rels to store
the membership. Or you could create a user group for the package
instance. This sounds like a lot of work.

2) Use the members of the nearest ancestor subsite's application
group. Not that people would know how to use that user interface.

3) Let you assign anyone you want, but maintain a "most recently
used" list of users that you've assigned (we maintain this list for
each individual user). Last option in the list is "Other...",
which'll take you to another page where you can search for your
preferred user by name/email/whatever. We could make a totally
general facility for this in the core (or the templating package) if
there's a desire for this.

These three ideas could also be combined, i.e., have a MRU list, and
when you say "Other...", we only list people with write permission,
who belong to the nearest subsite's application group.

Any other suggestions out there?

This is a pretty serious issue for sites with lots of users. And we
do want sites with lots of users, no? :)

/Lars

Easier (and better I think) than "most recently used" is to list
people already assigned to outstanding bugs.  That tends to be a short
enough list and simpler to code.  For our current needs there are
a lot more submitters than assignees so if you get all existing
assignees you are more likely to have the person you want on the
list while an MRU list won't help infrequent users.

I don't see any way around a search based assign (other than to push
it off into the group management pages) and since it has to exist
somewhere; standardizing it is probably a good idea and is
necessary to straighten out quite a few things on the admin side.

I expect for a more general bug-tracker you will need to also maintain
permissions anyway so the "membership" bit in the guise permissioning
is going to have to exist.

On the other hand I hate to see forcing everyone to go through a two
or three step process to assign a user to a bug (add to subsite,
permission or memberify, assign to bug) when for most projects simply
assigning any user to a bug (via the dropdown or a sitewide search if
missing from the dropdown) is good enough and simpler.

Jeff is bugging me about this again, so I guess I'd better do something to fix it. Here's what I'm planning on doing:

So what I'm going to look into doing is a drop-down list of all users currently assigned to bugs in this project, then an option called "Other..." or something like that, which, when the page is submitted is replaced with a widget to let you search for a user (perhaps we can do that with javascript, too, for people who have that enabled), then on second submit is replaced with a drop-down list of users that matched your search.

I'll see if it can become a templating system widget, so it's reusable.

I'm also going to change the permissioning logic so that if you're assigned to a bug, you're also allowed to actually edit the bug. We do that today with submitter: If you submitted a bug, you can edit it.

Comments?

/Lars

Alright, try it out here:

http://cph01.collaboraid.net:8096/bug-tracker/bug?bug_number=1&reassign=1

Log in as "mailto:peter@collaboraid.biz";, password is "1".

One annoying thing that I couldn't find an easy solution for is that when you do the search, and then enter an integer, or the empty string, then that simply gets accepted as a user_id or unassigned.

Other than that, it works now, it's part of acs-templating, so everybody can use it, and you can even supply your own search query if you like.

Try it out!

/Lars

Hi,

I am trying to use Lars new user widget in ad_form and I'm having some trouble getting it to work properly.

I'd like to use this cool widget to assign an owner to some object. In addition to the "owner_id" element my add/edit form has a "name" element that isn't optional... Now, when I request the form (without a key_id), enter a name, select "Search for other user..." in the pulldown and submit I get a request error because ad_form's "-new_data" block tries to insert ":other:" into my db. That is the value I submitted, of course, but somehow ad_form (or the user widget) neglects to render the user search field...

However, when I leave the name field empty in the add-form and select "Search for other user..." and hit submit a new form is rendered because name was required. This time the user search text box shows up and I can search for users as intended and fulfill the task.

I may have done something wrong when I defined my ad_form call but I can't discover it myself. Has anyone got any word of advise?

Here's my test code:

ad_form -form {
    table_id:key

    {name:text(text)                     {label "Name"}
        {html {size 50}}}
    {owner_id:text(user)                 {label "Owner"}
        {options $users_list}                                     optional}

} -select_query {
    select name,
           owner_id
    from   table
    where  table_id = :table_id
} -validate {
    {name
        {[string length $name] <= 200}
        "Name may not be more than 200 characters long"
    }
} -new_data {
    my_object::new -name $name 
        -owner_id $owner_id 
        -package_id [ad_conn package_id]
    ad_returnredirect "."
    return
} -edit_data {
    my_object::edit -table_id $table_id 
        -name $name 
    ad_returnredirect "."
    return
}



ad_return_template

Hi Lars!

I updated back the acs-templating/tcl/ dir to yesterday's status but that didn't solve the problem, I'm afraid. Still the same behavior.

I'm in no hurry, so I'll sit back and hope you'll fix it some day😉

Anyway, can you post here again if you fix something?

Alright, works here now.

I found out that there was an existing search widget/datatype that was close enough, so I just made a simple enhancement so that it can do the drop-down, then search, then drop-down page flow.

Look in /packages/bug-tracker/www/bug.tcl for how it's being used.

Hope it works for others, too.

It automatically redisplays the search string text field if there are no results, and chooses the only option if there's only one result.

/Lars