Forum OpenACS Q&A: SDM Changes

To do that, I created another table that maps packages to user groups
(teams) and modified a number of SDM authorization procs. On the way
I fixed some issues (like sdm_check_admin).

Ben, do these changes look allright to you? If not, let's discuss them
and see what we can agree to.

Right now AFAICS, only package admins can assign bugs/features to team members. I'd be hesitant to give someone package admin priviledge just so he can assign tasks to others. This has lead to a huge number of non-assigned bugs/features on the OpenACS SDM.

I'd like to be able to setup another action: assign_issues. So anyone with assign_issues priviledge, even a non-admin, could assign tasks to other people.

This would give us the possibility of having someone with Bruce Momjian's role kind of thing. He doesn't code, but he helps keep the effort organized and people focused on tasks. One thing that we certainly have missed in the OpenACS project (since Ben can't do _everything_).

Other things I am ready to do (if Ben/others think I should):

• Make the fix process a little faster. Right now you have to do too many click to be able to do it.
• When you close an issue, you go back to the Open issues, instead of closed ones (as it is now). Going to closed issues after closing one is a pain when you are closing a bunch of issues at a time.
• Give bug/feature reporters the ability to enter HTML code. I had to "view source" many times to be able to view the report correctly, when closing OpenACS 3.2.5 issues this week.
• Give bug/feature reporters the ability to submit a patch when submitting a report. That way you could see exactly which patch fixes what bug/implements which feature.
• Improve the CVS code. I have been looking into viewscvs' source code to learn how it works. viewcvs is a cvsweb clone, but written in Python. I can NOT, for the life of it, understand cvsweb's Perl code (I tried. I probably could, but it'd take me 500 more hours).

Phew! that's in for now. Please add your comments/suggestions here while I am up to it. It'd be really nice to get these improvements in so we can use them on OpenACS 4 and OpenNSD (and my other projects :))

Ok, I see the point now and I agree. But the code does not respect that. For example, right now in baf-assignments.tcl (to assign issues to someone) it calls user_can_edit_package_p, which only returns true if the user is a package admin. It doesn't even check if you are internal or not.

user_can_edit_package_p is probably doing what it's intended to do. But then we should have another proc, like user_can_assign_issues_p or just a query to check if the user is internal. In other words, we should change the permission model to check for the roles/actions (I did that to user_can_see_package_p).

"For submitting patches, try using the existing patch data model / code, so that a patch can be linked to a bug."

The existing patch data model doesn't allow that:

create table sdm_package_patches (
       patch_id                  integer not null primary key,
       user_id                   integer not null references users,
       package_id                integer not null references packages,
       package_release_id        integer not null references package_releases,
       submission_date           datetime,
       patch_file                varchar(200),
       patch_description         varchar(4000),
       accepted_p                char(1) check (accepted_p in ('t','f')),
       action_user               integer references users,
       action_date               datetime,
       action_description        varchar(4000)
);

"CVS improvements: what are you thinking of doing there?"

Mostly interface issues. For example, I like the way cvsweb/viewcvs shom me which lines have been added/removed/changed. It helps to quickly identify a change, learn from it, or spot an error introduced in a revision.

I haven't studied the CVS portion of SDM very much, but I think it puts somethings in the DB, and the admin has to manually update the CVS on SDM, which is not doable with something as dynamic as a CVS tree.

What do you think about the idea of assigning projects to teams?

1.) Copy the good things out of bboard - and bboard really works...

1.1.) Make the first page of sdm very similar to bboard. You see the title, posting-date, and the author of n-bugs on the first page. In brackets you could see if this bug has already a patch or not.

1.2.) Enable alerts. This way people know that a certain amount of regular visitors of openacs get that bug or the patch immediately. Additionally people can set a specific alert at a certain bug report that interests them.

1.3.) Show all new patches (parallel to show all new answers).

1.4.) Show all bugs that don't have a patch.

2.) Then it would be nice to have a flag at every bug that shows you if that bug has been fixed inside cvs. This way you could at one glance see what is new inside cvs. -- One more thing that is concerning all of ACS: We changed util_convert_plaintext_to_html, because you have to hit the "return" key twice while writing something in a textarea in order to display a new paragraph. Our solution is that every "return" is displayed like a regular new line.

We changed every "p tag" into a "br tag" and split all the numbers after "regsub -all" in half. I wanted to post the code but it messed up everything...

I am willing to take on the other things. As I said, working on general-comments is a bit delayed as it requires acs-messaging, and the glossary needs GC... general-comments will take preference I think, as a lot of other modules use it.

http://www.arsdigita.com/sdm/pvt/manage-incoming?package_id=8157 is where they can bulk-assign bafs to a developer. Also very nice.

Ben, if you don't like any of these things we are discussing, please chime in.

As you noted, the changes are simple, and it should only take a few hours to get them done and tested. Then, rock on 4.x ! :)

I've been trying to create a release to correspond with my RPMs,
version 3.2.5-2.  It won't let me.  Is SDM assuming all version IDs
are of the form either A.B.C or possible A.B.CbD, where A,B,C, and D
are all integers?  It is starting to look that way.

If so, is removing this restriction likely to be simple?  Why not a
version string?

Thanks!