Forum OpenACS Development: Scoping users to a package

Collapse
Posted by Lars Pind on
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

Collapse
Posted by Don Baccus on
Define a relational segment called "Bug Assignees" that draws its users from its parent's subsite membership group (in other words defines a subset of that membership group).

Oops, as you point out, no one can figure out the UI for the subsite and even worse, we're broken in that registered users aren't automatically members of the main subsite's membership group.  I have a proposal to straigten this out in mind for 4.7 that I've not written up yet (basically the registered users group should go away and make registered users == members of main subsite).

This is where the dotlrn framework really has done some nice things and where we should be looking for some way to generalize things and apply them to acs-subsites.

For now the best you can probably do is to create a relational segment "bug assignees" that is drawn from registered users, gnashing your teeth at the thought of someday having to provide an upgrade script if we ever get acs-subsite straightened out and you want to scope users to members of the subsite rather than all registered users.

Check out how dotlrn create professors, students etc for practical examples.

It's very fast to generate a list of members of a relational segment ...

I think the MRU idea is really a presentation issue, not a "who can" issue, isn't it?  There's no reason why you can't define your own relational segment type that keeps track of the MRU stuff in its type extension table.

Collapse
Posted by Jeff Davis on
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.

Collapse
Posted by Dave Bauer on
In working on the new survey package, we ran into a similar problem.

I was creating a "send bulk mail" feature and we wanted to be able to send mail to people who had not yet completed a survey. To find this out we needed to know every user who could take the survey.

Right now I am using a dotlrn relational segment whuch obviously won't work in a general OpenACS package.

Any solutions would be very helpful.

Collapse
Posted by Lars Pind on
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

Collapse
Posted by Jeff Davis on
The only other thing I might suggest it to have "Assign to myself" at
the top if it makes sense for a given user.  I think a common use case
will be for individuals to claim bugs for themselves.
Collapse
Posted by Lars Pind on
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

Collapse
Posted by Tilmann Singer on
Very cool!

Just a minor suggestion: I think it would be more comfortable if an empty search result would allow to immediately search again by already offering the search field instead of having to select the only option "Search again..." and submitting before that.

Collapse
Posted by Ola Hansson on
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

Collapse
Posted by Lars Pind on
Ola,

Sorry, yes, I broke it earlier today trying to implement Tilman's suggestion above, and I haven't had time to fix it.

Try "cvs up -D 2002-09-14" or something like that, that at least works.

The problem is that the only way I know to tell the form builder that you're not quite ready to submit is to do a validation error. Unfortunately, that's also somewhat ugly, and there's a problem in that the time that the validation proc is called before the widget proc, but it's the widget proc that knows that we couldn't find any users as a result of the search.

I'll try to find or create some other mechanism to tell the form that it's not done, so that "form is_valid" isn't true, and the right time to do it, before the form is rendered. Hmm, we need a message-sequence diagram for the form builder.

/Lars

Collapse
Posted by Ola Hansson on
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?

Collapse
Posted by Lars Pind on
Sure, will do.
Collapse
Posted by Lars Pind on
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