Select from various users for assigning issues

I added the following code at line 98 in issue.inc::project_issue_form:

$res = db_query("SELECT u.uid, u.name FROM {users} u LEFT JOIN {permission} p USING (rid) WHERE p.perm like '%access projects%' AND u.uid <> " . $user->uid);
while ($usr = db_fetch_object($res)) {
$assigned[$usr->uid] = $usr->name;
}

This looks up all users who have 'access projects' permission and appends them to the list of possible assignees.

That solution would be unmanagable on a site like drupal.org with 5000+ users who can access issues. I'd like some more UI suggestions before I try and solve this.

Why not have it be a a textfield rather than a drop-down box? That UI works quite well for the 'Authored by' component of nodes, for example.

Clearly a drop-down list with 5000 entries will be unworkable.

How about an admin option for selecting the accounts which appear in such a list? Presumably the admin would choose a much smaller subset. At least in my applications, the number would be small.

+1 for this feature. I understand the limitations of the drop downs on big open-source projects, but think there must be another way to meet the need for managers to assign tasks to team members.

In the meantime, I'll use the code supplied above. Thanks!
- Joe

For what it's worth, SourceForge allows for a text-input that is immediately verified against the database to trap typos. Presumably, if you want to add someone to your project, you will know their name.

This might be extended to allow for a user name or a role name, so you could use a shorthand of "developers" to add your entire dev staff as potential assignees.

The patch provided above doesn't work for me. I've made a few changes while trying to get it to work see below. Has anyone else had better luck?

I an not sure the AND u.uid=".$user->uid) is necessary... wouldn't the current user already have passed the validation test to be able to edit this issue?

<code>	     	  		
$res = db_query("SELECT u.uid, u.name FROM {users} u LEFT JOIN {permission} p USING (rid) WHERE p.perm like '%maintain project issues%' OR u.uid =" . $user->uid);
while ($usr = db_fetch_object($res)) {
	$assigned[$user->uid] = $user->name;
}

Can this (assigning to any users with permission as a dropdown) be added as an option? I know it won't work here on Drupal, but it's a highly useful feature for smaller usage.

Of course, the user name text field or some sort of alternate pick list would be more permanent solutions. Perhaps filter by those subscribed to a project? That is, the user drop down would only show users that are subscribed to the project. If this is still too large a group (i.e. people monitoring status but not actively involved with the project), perhaps an additional "developer" flag ("add myself as developer") to indicate that you are associated.

Joe: I think you just had a couple typos in your code. When I fixed them, it worked for me. You fetch the database results into an object with a variable named $usr but refer to variable $user in your statement to store the results in the $assigned array. Corrected code below, which I inserted at line 245 of the DRUPAL-4-4 version of issue.inc.

$res = db_query("SELECT u.uid, u.name FROM {users} u LEFT JOIN {permission} p USING (rid) WHERE p.perm like '%maintain project issues%' OR u.uid =" . $user->uid);
while ($usr = db_fetch_object($res)) {
	$assigned[$usr->uid] = $usr->name;
}

I was using the patch posted by Chris but found that it no longer works with 4.5. I don't know much about php and mysql queries, but I'm trying to learn. I have noticed that (rid) is no longer in {users} I think that's why it doesn't work in 4.5. I think I'll try and figure it out.. unless somebody beats me to it. I'd like to add that this would be a good feature to implement somehow on a permanent basis. Perhaps an option that could be enabled for those of us who want to use it. I know lot's of sites have too many users to make it useable. But a few of us that use it in intranets and campus production teams find it very useful. Also, this should probably be a separate request, but I'll just field it here first, when an issue gets created and assigned to a user, could an email be sent to that user alerting them. I know notify will send if anything is updated on the site, and subscriptions will work for comments to a project, but an email when being assigned would be nice. Thanks for a wonderful module.

ok, my bad on the email subscriptions.. It's already in there.. I just completely missed that for the past several months.

Ok, this is probably not a very nice way to do it, but it works for me.

$res = db_query("SELECT u.uid, u.name FROM {users} u LEFT JOIN {users_roles} p USING (uid) WHERE p.rid =3 OR p.rid =4" . $user->uid);
while ($usr = db_fetch_object($res)) {
    $assigned[$usr->uid] = $usr->name;
}

the p.rid = gets the rid of the assigned roles you want to have in the dropdown list from the role table in your db. It works for me in 4.5.

Also, I inserted it at line 237 in issue.inc

pegmonkey.
thanks for the hack. works.

as for the recent feature requests. I agree. We used phpcollab for past 3 years but I am setting up drupal andusing this module despite it lacking some of these features. I might make time and add them in myself...at least a few of them.

Maybe we should create a autocomplete field for this? As it is now the feature does not make much sense and should be rather replaced by radio buttons...

Most probably, the project number will be far lower than that of members.
In my opinion, the admin should assigns an user to a project (maybe giving him also some particular grants), so will be quite easy and logical (from the UI / logical process perspective) have a multiple SELECT or a CHECKBOX-able in the user configuration.
I mean:
1) A project-owner should decide to restrict the scope of a project to the project members only (they must be registered users, of course) or leave the project public (all registered users are project-members without explicit assignment). The flag "RESTRICTED_SCOPE" could be defined as Project attribute.
2) If someone is enabled to manage projects, he/she should be automatically allowed to access to the user list and to manage a special page where he can only enable/disable the user membership to the projects he/she owns. In a checkbox-fashioned list, the projects "not owned" should be disabled (what I prefer) or hidden.
3) It would be fine to have in a project (few) different roles such:
- stakeholder/viewer (read only)
- reporter/issue submitter
- developer (responsible for resolving the issue)
They be intended as actors (active participants) in the project, accessing to the project pages.
4) Anyone, within the project scope, can also subscribe issues to be warned when something new happens.

I will be happy to participate activelly to writing code. I'm convinced to be a valid PHP developer, but I'm totally new to the Drupal framework, so, if someone wants to mentor me or give me guidelines, I will engage myself at work.

Warm regards. Michele.

Michele, I'll be happy to help you implementing this. The only concern is that project.module still has to be usable here on drupal.org afterwards.
Ajax-based autocompletion is now available in Drupal core which should amek this task easier.

I tried using pegmonkey's code on the 4.6.0 version to be able to assign other users but it still does not work. Is there anything else I need to do or missing?

gosh, michele's description makes a project look a lot like an organic group. actually, thats not bad thing because then multilpe node types like 'issue', idea', ' etc. can be node types within the group. this is probably worth exploring, but i'm all talk. hopefully someone else will get inspired.

Moshe's point is a good reminder: the most direct and probably the best way to improve project module (beyond bugfixing and other tweaks) is not to write in new functionality, but to integrate it well with what's available already through other modules and APIs. In this case, there's no point in reinventing groups--the point is to use them.

I'll rough in an approach to integrating organic groups. I'm thinking:

* many to one relationship between groups and projects--one group can have many projects, but each project can have only one group
* tasks can be assigned to anyone in the associated group.
* then, e.g., block with each group member's assignments, with percents.

Here's an initial patch implementing organic groups support.

If a project has been assigned to an organic group and the current user is a member of that group, all group members will be added to the select for assigning the issue.

Fuller organic group integration would probably call for a bit more work, e.g., facilitate/automate creation of a group for a particular project. I'm interested in feedback on this start. Is allowing project.module to take advantage of og a priority enhancement?

That sounds pretty complex, even somewhat awkward. The good part is that the changes are small, but that's not the primary concern. Ease of use and adminsitration is.

That said, I've yet to check out the og.module in detail. I do know that I'm not happy with the "groups as node" paradigm (not relevant in this discussion).

Please do not commit this yet. It's not a drupal.org priority either.

Okay, I hear you.

Without going the full og integration route, one simple option would be to provide a new optional project field, "maintainers", for a comma-separated list of user names. Then we could add to these to the array of values for assigning issues, and also display a list of maintainers. (Or, of course, we could do it properly and create a new linking table, project_maintainers, with pid and uid fields.)

I know I would use this on some of the projects I currently maintain on drupal.org.

nedjo,

That sounds like what I'm looking for. Anyone have a patch for HEAD?

Now that we have registered maintainers via cvs.module (thanks, Derek), we need at the least a way for other modules (e.g., cvs) to add to the list of available assignees. Here's a start--a 'project_assignees' hook. The hook would return an array of $uid- => $user_name pairs to add to the assignment options. We could implement this hook in other modules like cvs, og, etc.

There's been talk of doing this instead as an autocomplete. Okay, but at present we have no way of limiting autocompletes (which are when it comes down to it dressed-up textfields, not selects) to a set list of options--it would be open season for assigning issues.

fascinating. ;) i think i like it. i'm definitely more in favor of a select box than an autocomplete.

i was thinking of solving this problem by adding a new tab to project nodes to control maintainers (much like the cvs access tab). i was thinking anyone in this list (which wouldn't necessarily need cvs access) would have the ability to:

- have issues assigned to them
- edit the project node
- see this project in their "my projects" link

the downside is that folks would have to remember to add people in 2 places. this hook is an interesting approach, too. then cvs-access users would automatically be able to have issues assigned to them, and other modules could add to the list, too. plus, someone could then just write another contrib module to add the tab i'm talking about (via hook_menu()) and accomplish at least one of the goals via this hook. ;) of course, this wouldn't solve the other things i was thinking of, but perhaps a better RSS subscription to projects you care about is the solution (instead of "my projects") and maybe this editing of the project node itself isn't such a good idea...

i'll have to think about it some more, but i'm giving this a tentative +1... it certainly doesn't prevent more fancy functionality down the road, and is a flexible way to handle the task at hand.

I agree that an autocomplete field would work here. You need a drop-down menu with available names.

Not sure we need a hook for this. From what I understand, all the functionality is currently embedded in the project.module itself.

Interesting nonetheless. :-)

I agree that an autocomplete field would work here. You need a drop-down menu with available names.

you mean "i agree than an autocomplete field would not work here", right?

in terms of the hook: no, the cvs access tab stuff all lives in the cvslog/cvs.module, not in project. so, at the very least, we need to do something like:

if (module_exist('cvs')) {
  $assignees = cvs_get_issue_assignees($nid);
}

however, i'm still in favor of the hook, since it would allow other contrib modules to handle this differently. maybe some site wants to do issue assignment based on user roles (as proposed in other issues, e.g. http://drupal.org/node/22338). if we used this hook, they could write a trivial contrib module that provides the role, and fills in the assignees accordingly. maybe people want to do this via OG, and all subscribers to a given group should be able to have issues assigned to them for projects from their group... i could go on, but i think you get the idea. ;)

Hmm, I guess we could do without the hook and just do this through form_alter, in cvs.module, og, or wherever.

Ok, agreed. A hook works for me. :)

Actually, I think it might be cleaner/more flexible just to stick with form_alter. So I've roughed in an idea for allowing project maintainers to assign issues to each other, http://drupal.org/node/67251.

i took a stab at the form_alter() patch nedjo posted above, and a) it's still not quite working and b) it's really complicated to get it right via form_alter().

i think this would be a lot easier as a hook, with the current project nid passed in as an argument. project would then be responsible for filtering out duplicates and sorting the results from all the hooks in 1 central place. see my comments and patch in http://drupal.org/node/67251 for evidence of the headache i'm talking about. ;)

thanks,
-derek

in fact, based on the headache w/ form_alter(), and discussions with halkeye about his new http://drupal.org/project/subversion module, i think there's yet another approach that's neither form_alter(), nor a hook...

http://drupal.org/node/69556

Here's a module that allows users in given roles to be added to the list of assignable users via a permission. Not the full solution we're looking for, but potentially useful on smaller sites where users may be assigned to all projects.

1. install and enable
2. assign permission 'assign and be assigned project issues' to desired roles (anonymous and authenticated user may not work, haven't tested thoroughly).

Tested on 4.7, not yet on HEAD, but might work there too.

nedjo: i love it. i was *just* about to write something similar myself. ;) however, why don't we just fold this new perm into the project_issue.module itself? the d.o admins don't have to grant this new perm to any roles here, but it'd be useful for other sites. there wouldn't be any new settings, etc. it's just a new perm sites have access to. if they want it, they use it, else, they get the current behavior. then there's no new module to install, no new project node, etc, etc. looks like it'd be about a 10 line diff. ;) care to roll a patch, or should i? as i said, i need this functionality yesterday, and was *just* about to write almost exactly this...

let me know what you think. thanks!
-derek

Based on nejos patch I was able to write something to extract a list of project maintainers from CVS module. This should work pretty nicely on contrib modules for d.o, while the Drupal project it only works to assign people with core commit access.

It works by having the cvslog module populate the assigined dropdown with project maintainers and contributors who have been active in the last 180 days. Only people who end up in that list or administrators can assign to this category, as I still belive having a general free for all assigning just leads to chaos.

So after all that, I am wanting to do the same thing. But Drupal is now 4.7.XX So what is the final patch?

Adding a 'me too' to this.

I dont really mind what form the final solution takes, but I would like to be able to define a small subset of users (perhaps only those with 'maintain projects' permission or something) to the drop-down list of available assignees. I guess it would also be preferable to make this list project specific (ie: the list of assignees are only those who maintain this particular project).

I guess its difficult to pin it down with the project module being a moving target (its gone through a lot of changes in the last year to two), but I hope something can be worked out soon. For the time being, I'll probably do something based on one of the above patches. (That last one sounds nice, but I dont currently use cvs.module, though I do use cvs).

FYI, i'm using nedjo's little extender-module from comment #37 on a site of mine and it's working fine. that's the interim solution. there's a new role, you just add users to that role who should be able to assign/have issues assigned.

cheers,
-derek

Not using CVS, and have a small user pool on our dev site where we track issues & projects. Would like to just make the light mod to issues module and leave it there for now.

Is the simple update above still relevant to the recently updated 5.0 version? I'm looking through the file but not seeing where it would drop in - line numbers above no longer seem correct.

Not that this 3+ year old thread needs more opinions... an "allow issue assignments" setting would be all that is needed to make this feature available for smaller sites. Seems like this was developed for a outlier case in drupal.org - most dev teams would be small and assignability of issues is pretty std. functionality.

Thanks on any 5.0 patch for issue.module.
-Greg

aside from missing a .info file, the module from comment #37 probably still works fine on a 5.x site. give it a try. ;)

gbear: instead of just stating "this old issue needs more options", consider being a) more appreciative and/or b) contributing your own solutions... if you're not a coder, and not able to work directly on (b), at least be more considerate of (a). you can also help by taking a more active role in the issue queue here (i'm not the only one who can see if new issues are duplicates, etc), and help out in other ways. if you're a local user of project + project_issue, i'd really love to have you involved in testing the various patches i'm generating all the time to fix things and add new functionality. so, you don't just have to supply patches to be helpful. you could also help by working on the (almost entirely non-existant) documentation. see http://groups.drupal.org/node/2199 for a list of ways you can contribute to project + project_issue development.

thanks,
-derek

Hey Derek - sorry, did not mean to be offensive. We use & love the project modules. The best part for us is it is lightweight, and I don't have to maintain some side-system like basecamp, can just tick off work as it gets done.

Attached my patch from Nedjo's work above rolled into the 5.0 version of project_issue module. It's very simple & lightly tested... works great for tracking (& assigning) issues for a 3 person team. Thanks to the giants whose shoulders I'm standing on.

subscribing

Patch applies, but breaks my site (I get blank pages only). Probably some update to HEAD since January has broken it. I may have some time to play with it next week, but does anyone else already have an update?

Hi

Looking at gbear's patch, it could be improved by splitting the 'assign and be assigned project issues'
into 'assign project issues to others' and 'be assigned project issues' permissions.
If someone did not have the 'assign project issues to others' permission, the code should work as the unpatched version does currently, allowing Open Source sites with lots of potential developers to continue working as they do now. This is a fairly simple change to the patch code.

My need is have a solution that allows for 3 levels :-

• Team Manager, who assigns work, but cannot be assigned work (does not do any).
• Team Leader, who assigns work, and can be assigned work.
• Team Member, who can be assigned work, but can only assign it to themselves.

Different combinations of the 'assign project issues to others' and 'be assigned project issues' should be able to achieve this and keep backwards compatibility.

Does anyone else have any suggestions on improving this patch, or different usage patterns that it should be made to cope with.

Nick

Indeed, 5_project_issues_assign_users.txt is successful in the patch yet the results are.

PHP Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ')' in /var/www/sites/all/modules/project_issue/project_issue.module on line 64

This patch contains my modifications to gbear's patch (to split the 'assign and be assigned project issues' into 'assign project issues to others' and 'be assigned project issues' permissions) as outlined in comment #50.
The patch was created against the latest version of head.

Nick

Was just about to update the previously posted patch to add the missing commma.

Thanks. I'll have time to check this out later this week, probably Thursday.

Patch #52 has a bunch of code-style bugs (wrong whitespace, poorly written/formatted comments, etc).

Also, I'm not 100% thrilled with the names of the new permissions, though it's too late (2:20am here) for me to have better suggestions right now.

This line is hard to read and understand:

$assigned = array( $node->assigned => ($node->assigned && ($account = user_load(array('uid' => $node->assigned))) ? $account->name : t('Unassigned') ) );

After reading it 3 times, I see what it's doing, but it should be re-written to be more self-documenting and obvious. 4 lines of clear code are better than 1 twisted line trying to do too many things, IMO. ;) I'll admit that you're mostly just copying a similarly twisted line from a little bit higher in the existing code, but that line only still exists because I hadn't seen it yet and given it some much-needed edits for clarity. ;) Also, part of the convoluted logic that this accomplishes (for the $node->assigned == 0 case), is just undone a few lines further down in the patch:

+      $assigned[0] = t('Unassign');

Patch #52 provides great functionality. In testing it I did find a bug that impacts what "users" will be displayed in the pulldown (inherited from previous patches?).

If a user's role is only "authenticated user" they will not show up in the pulldown (that allows you to assign the issue to them). This occurs even though they have been assigned permissions. Testing shows if the user has been assigned another role such as "admin", "moderator", etc. and you assign those roles the proper permissions, they will show up in the pulldown.

It seems the role of "authenticated user" is different from other roles. The code that queries the database:

$result = db_query("SELECT u.uid, u.name FROM {users} u INNER JOIN {users_roles} ur ON u.uid = ur.uid INNER JOIN {role} r ON ur.rid = r.rid INNER JOIN {permission} p ON p.rid = r.rid WHERE p.perm LIKE '%%be assigned project issues%%' ORDER BY u.name");

is somehow not picking up "authenticated user" or the permissions that are assigned (in Administer/User management/Access control) are not being picked up.

The code from the additional module in #37 is working fine in a Drupal 5.2 environment (with several other modules) and Project/Project Issue Tracking 5.x-1.0. It adds a new line of permissions in access control, so that only people who are part of a certain group are added to the dropdown. Just letting everyone know that it still works in the latest environment, so that perhaps it can be considered in the patch, or added into the main code in the next release.

FWIW, there's a ready-to-use version for D5 in my sandbox:

http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/fgm/project...

Is there a consensus on whether this will be rolled into project_issue at some point or not ?

while we definitely need to something better than what we have now, i'm not convinced that this is the best long-term solution.

in the mantis bugtracker, admins can add individual users to projects, with varying levels of access. i don't think we need our solution to be as robust as theirs, but i do think a role based solution is not sufficiently fine-grained enough, especially for a site like drupal.org.

Indeed, this has already been discussed in this issue : such a feature is obviously not appropriate for d.o. due to the number of devs concerned. But, as others have mentioned, it is useful for smaller sites (dare I guess they are the majority of project* module users ?) who just don't want the overhead of something like mantis or basecamp.

To sum things up, the main other suggestions in this thread appear to have been:

1. additional permissions ("assign" and "be assigned")
2. use an other UI (autocomplete instead of combo) to tackle longer lists - apparently rejected by Dries and others
3. integrate with OG (apparently dismissed as too complex)
4. create a new hook
5. use the members from the CVS integration tab (requires this to be setup, good for d.o., not so good elsewhere)

It seems you are hinting that this should be kept outside project/project_issue because there is no short/middle-term solution being envisioned to be rolled into these ?

i'm saying i want to do it once, and do it right. believe me, if you spent any time working in this code base, you'd feel the same way... ;)

because the module is open source, people are free to apply the patch if they see fit, update the patch for newer versions, etc, etc.

the general direction i outlined in my previous post is the proper long-term solution i believe -- namely, a way to add individual users to projects, with a few basic 'levels' of power, ie 'be assigned', 'assign'...

When you start affiliating people with projects, and putting nodes into those projects (i.e. issues), you are veering *very* close to organic groups. It might make sense to experiment with making the project node into a group. dww started on an og_project glue module which probably merits further work.

@moshe: i'd want to know the prospects of OG making it onto d.o before we go in that direction. like it or not, project module has close ties to it's deployment on d.o, so it affects the development of the module.

Agreed.

We already know that OG is acceptable for use on the d.o hardware because groups.drupal.org uses it. So if Dries won't run it on d.o, i think a valid alternative is to run projects.drupal.org as a separate site. This is in line with Joomla (http://forge.joomla.org/). Project* is never going to become a first class module suite if it is limited to the conservative way that drupal.org has deployed modules. Thats not how modern Drupal sites are built. As evidence, look at the MTV, and Observer and Popsugar. They all make heavy use of quality Contributed Modules.

"we won't code around Drupal any longer"
- hunmonk

a) OG + project has a lot of promise. I haven't given og_project any love recently, but I should. However, OG doesn't have a notion of different roles within a group, right (other than the group maintainer and subscribers, which is hard-coded and inflexible)? We'd need a pretty major new concept in OG for it to actually solve this particular problem.

b) The kind of thing hunmonk is saying in #58 is exactly the approach i spelled out at http://drupal.org/node/69556 and I think that's a reasonable approach for the d.o use-case, especially now that we're going to move away from cvslog.module to versioncontrol API.

c) Both of these approaches are totally over-kill on most project* sites. For example, security.d.o and nmi.cs.wisc.edu (2 non d.o project* sites I maintain) both run this patch/helper module. It's all that many sites need.

Therefore, I'd be in favor of:

1) Folding something like this site-wide permission stuff directly into project_issue (probably after splitting the permission -- but not 100% sure what I think of that, yet). d.o doesn't have to grant this/these permission(s) to any roles, but for a large fraction of other sites, that'll solve their problem entirely.

2) In conjunction with the Project node UI redesign effort and the Project D6 porting roadmap (in particular, ditching cvslog.module in favor of the versioncontrol API), finally fixing http://drupal.org/node/69556 at least for the d.o use case for a medium-short-term solution here. Maybe as part of this we'll implement the new hook, maybe not.

3) Long term, giving og_project some love, and investigating what we could do if we turned projects into groups. My initial og_project use-case was projects were site-wide, and there were groups of users that interacted with different groups. Another use case is a set of projects that belong to each group. Yet another is the one we're talking about here: each project *is* a group. All of this requires more thought, and undoubably some more code. I don't want to commit to this approach just yet, especially knowing that it's probably going to require some pretty massive changes to how OG works so that we can have a notion of something like "roles within the group", etc.

Another approach that would probably work well both on d.o and non-d.o sites is that the pool of available assignees for a given issue includes everyone who added a followup to that issue. I think that could compliment basically all of the other approaches being discussed here.

Finally, I'd be opposed to moving project* off of d.o itself. Aside from the issue queues and downloads, all that d.o itself would be left with is a forum (and a front page). That doesn't make sense to me. I totally agree we should start making better use of other high-quality contribs instead of re-implementing crap ourselves in project* under the illusion of "no new modules to maintain on d.o". But, that's already happening (comment_upload for issue followup attachments, for example), and will only continue (we've already convinced Dries to let us use views on d.o). If it turns out the best way to solve a bunch of problems long term is to deploy OG and og_project on d.o itself, then we'll cross that bridge when we come to it, but I don't think we should agree ahead of time to move project* off d.o. For the same reasons that people got so bent out of shape over #drupal vs. #drupal-dev in IRC, the actual development of the code is central to the drupal project, and should remain a key component of the "landing site".

@dww - well said.

minor point - og currently has 5 "roles" per group
- manager (only 1)
- admins (a few)
- subscribers
- logged in readers
- anon readers

we could always make more. there have been calls for more in the past. perhaps project is a good use case ... implementation won't be too hard since the usage of these roles would be left to og_project and others.

@moshe: Cool, good to know.

Now, before this issue gets way too side-tracked, I'd like to refocus it:

This issue should *only* be about the 1 or 2 new permissions based on the code nedjo originally posted in #37, which fgm has in his sandbox (#57), and which NT split into 2 permission in #52. Basically, someone needs to start from the patch in #52, fix the things I mentioned in #54, and post it here. I'm setting this issue to "unassigned" since I'm not assuming nedjo will definitely be the one to re-roll this, so if you're planning to work on this, please assign it to yourself first to avoid duplication of effort. Discussing the merits of 1 permission or 2 is still relevent in this issue, so if people have opinions about that, let's hear them.

http://drupal.org/node/69556 is where we should talk about the d.o use-case, the stuff hunmonk mentioned in #58, version control API integration, and project node UI improvement stuff regarding this particular point.

I'm not sure where to continue the project-as-an-OG discussion, but the og_project issue queue doesn't quite seem right (since it's all design at this point, not a particular issue we're specifically working on). I think a new post in the http://groups.drupal.org/issue-tracking-and-software-releases group makes sense for this, if anyone else is inspired to continue that discussion at this time.

Thanks, all.

New sandbox version 1.2 includes NT's permission split in the existing form_alter mechanism (that is, not touching project_issue.module).

Please re-roll as a patch against project_issue.module itself. I don't think we want a separate module for this.

i have concerns about how this nice small solution will present upgrade challenges in the long term. especially considering the permissions crammed into a long string crap, this could get very messy if the longer term design conflicts with this approach.

as the person tasked with forwarding the featureset of project module for drupal.org, i am strongly against a short-term solution which will provide no benefit to drupal.org, and could cause us upgrade pain in the future. it's not that hard folks. design something that will work for a wider range of use cases, _including_ drupal.org, and deploy it once, done right.

you'll notice by the nid on this issue that it's one of the oldest on drupal.org. project module has lived a long time without this feature, i think it can make it a little longer so that it's done right.

@hunmonk: I hear what you're saying, but I think you misunderstand my point. It's 100% impossible to design a solution to this problem that's "right" for every kind of site. This is something we have to be flexible about. I'm not talking about adding these 2 site-wide permissions now, and then removing them later once we get #69556 working. I'm proposing we add site-wide perms and leave them in place forever. For some sites (sec.d.o, nmi.cs, the ones people in this issue are talking about, etc), that'll be all they'll ever need, case closed. For huge sites like d.o, the site-wide perms won't do much good, so we won't give those out to any of our roles. For this site (and other similar, huge sites), we can do something like #69556.

However, #69556 won't work well *at all* on sec.d.o, even if we spend 30 hours on mockups and wireframes and design arguments. We've got a ton of projects (potentially one for every d.o project), but only a tiny handful of users, no direct notion of project maintainers, etc. We just have a small pool of users (the entire security team), and we want to be able to freely assign issues to each other as appropriate. It'd be a huge pain in the ass to have to go in and add ourselves as "issue maintainers" to each project on sec.d.o each time we a) add a new user to the security team or b) add a new project. The same is true for many sites. They might have a bunch of projects and a small # of users, and they just want to say "these users can assign issues to other people", and "these users can have issues assigned to them", but not have to touch *anything* per-project.

So, this is not a question of rushing in a hack solution as a short-term fix until we get around to implementing something better. This is acknowledging that project* can be useful to non-d.o sites, and having a general solution to a problem that isn't quite fancy enough for d.o itself, but is exactly the right approach for many other sites.

And, as a patch against project_issue, we're talking about 10 lines of code, tops. You won't convince me on the "we shouldn't have to maintain this bloat" argument, especially since this is exactly the functionality we already need (and are using) on sec.d.o.

It's 100% impossible to design a solution to this problem that's "right" for every kind of site.

i think that's a poor excuse, and that there's a good chance we can do better than this 'bolt on' solution.

This is something we have to be flexible about.

of course. but sticking two completely disparate permissions systems in isn't necessarily being flexible. it could very well be less flexible.

It'd be a huge pain in the ass to have to go in and add ourselves as "issue maintainers" to each project on sec.d.o each time we a) add a new user to the security team or b) add a new project.

this assumes that a system that assigns individual permissions can't support some kind of automation in this case. i mean we do have actions in core now... ;)

it's possible that i'm full of hot air, and your plan of commiting both systems is the best way to go. but my instinct is telling me otherwise, and i'm suggesting that we spend a bit more mental effort trying to come up with a better overall approach.

Here is the patch version.

Now, if we go ahead with implementing the feature directly in project_issue, it might be possible to avoid hook_form_alter and link the mechanism directly in the relevant forms. Not sure whether this gains anything performance-wise, though, but I suspect it could.

@fgm: I see no good reason for project_issue to form_alter() its own forms. ;)

@hunmonk: Believe me, I've spent quite a lot of mental effort on this problem, both for d.o and non-d.o cases. You seem to think that because this issue was recently bumped that this is the first I've considered any of this. If you think about it long and hard (as I have), you'll agree there's no single approach to this problem that will work well for every kind of site at every scale. These permissions are not "bolted on", nor do they conflict with other possible approaches. If any of this were a step backwards and a hack, I'd say it should go in a separate module and be done with it, but that's not what I'm arguing, is it? ;) No matter how fancy you try to make the UI and methods for automation, it's totally overkill and way too complicated for a large fraction, probably the vast majority, of all project* sites. Even if there's a fancy way to automate a difficult task, better yet is to just use a simple solution to the problem in the first place...

@fgm: Oh, 3 other problems with your latest patch:

A) you had + 'be assigned project issues', listed twice in hook_perm().

B) It doesn't look like the JOIN on {role} adds any value to your query.

C) This WHERE clause looks wrong: WHERE p.perm ='%s'. Due to the insanity of the {permission} table (see http://drupal.org/node/73874), perm is just a giant string. You need something like WHERE p.perm RLIKE 'be assigned project issues'. Also, since it's just a string literal, there's no good reason to use '%s' in there.

p.s. In the future, if you could use "cvs diff -up", that makes it nice since the function names are included at the top of each hunk of your patch file. Thanks.

@Dww: thx for the review. I fixed these in the new version. The JOIN to role was a safety net for the JOIN to perm: it worked around DB inconsistency situations where a rid might have been present on a users_roles with the appropriate permission and the role would be missing, due to the lack of referential integrity in our DB and bugs having occurred previously leaving the schema inconsistent, by making sure the role really existed. But since you think it's useless, I've removed it too.

I would rather not use RLIKE because it is not ANSI and will cause problem on alternate DB engines.

Now, to switch from hook_form_alter to integrated behaviour in the forms, I've prepared it by extracting the assignees generation in a separate function, but considering how complicated the handling for these forms appears to be, I'm not sure where these additional assignees should go when not using form altering.

@dww: if we're looking at using OG to handle this functionality down the road, it doesn't seem to me that OG and this fix would play well together. also, if we move towards using OG, then we have _three_ control systems: this one, #69556, and OG -- seems messy.

while i trust that you have spent time thinking about this issue, i'm not simply going to take your word that there's no better available solution... ;) so i think we should keep exploring this until we reach a consensus. i'm a reasonable guy -- if what you're proposing turns out to be the best solution everyone involved can come up with, then i'll get on board, but i'm not there quite yet.

@hunmonk: I'm willing to keep convincing you about this for a little while longer, but none of us have unlimited time. A few random thoughts about your continued objections, in no particular order:

- Global, site-wide permissions don't conflict with either OG nor #69556. Lots of access-minded modules provide global "access all foo" style permissions, that are site-wide, and circumvent the more complicated access stuff provided by the module. "access all views" and "access all panels" immediately come to mind, but I'm sure there are countless others. As a minor concession to your hesitation around this point, I'd be willing to add 'all' or 'any' to the names of these permissions some how to make it more clear these are the site-wide overrides for whatever more fine-grained stuff we might add in the future. Something like:

+    'assign all project issues to others',
+    'be assigned any project issues',

- Exactly how OG-based assignment and per-project-maintainer-list-based assignment (#69556) are going to inter-operate, if at all, seems a little outside the scope of this discussion. Honestly, I think if we implement #69556 in the medium term, and eventually move towards projects are OG's, I have a feeling we'd just *switch* from the custom project-maintainers code from #69556 and convert those to OGs, much like we moved the custom project code for followups to IFAC. I'm not 100% sure about this part of the topic yet, but I don't think we need to even really start worrying about it until we start working on #69556, and we don't have to be sure until we start working on projects as OGs (if we ever do). As I mentioned in #66, I'd rather not continue discussing this particular aspect in this thread, since I don't believe it has any bearing on what we're trying to accomplish here.

- While it's over-engineering for this particular patch, I'd be willing to introduce the new hook_project_assignees() (or whatever name we can agree on) as originally proposed by nedjo in #28 to make it easier to expand this in the future by other means, and give people easier access to write their own modules that interact with this list. project_issue_project_assignees() (project_issue's own implementation of the hook) can add everyone to the list who has the 'be assigned any project issues' permisison, since that perm will be provided by project_issue itself. Then, versioncontrol_project.module can implement the hook as part of #69556 to automatically add everyone with version control access, etc, etc. This is exactly how I imagined #69556 working eventually, but I didn't see the need to introduce the hook at this point, just to add these global permissions. I'd rather add the hook once we're sure we need it and have a slightly better idea of who's responsible for what. However, I'm *pretty sure* we'll want it eventually, so if it makes hunmonk happier now to feel like we're working on the Grand Design(tm) already, I'm willing to put it in now.

@fgm: Thanks for the new patch, definitely getting closer. It's obviously still using the form_alter() approach, which I'm not down with, and there are some other minor issues (whitespace, capitalization of LIKE in the SQL query which I find improves readability, etc). However, it's unfair to keep marking your patches CNW when I'm so much more familiar with the underlying code and could just do it myself how I have in mind. ;)

So, I'll take the next stab at re-rolling this. I'll also use it as an opportunity to introduce hook_project_assignees() to make hunmonk happier. Keeping hunmonk happy is an important goal of mine these days. ;)

the hook idea seems reasonable, because

• it's obviously a complicated issue
• instead of trying to meet everybody's needs, we can farm out the permissions to other modules, to do as they see fit

this seems to dovetail well with putting the global hooks in project_issue -- that would be where they belong.

so i'd be in support of putting in hook_project_assignees() (or whatever), and having project issue implement this hook to provide this feature.

note that i haven't reviewed the patch yet, which i'd still like to do before it lands.

Replacing your code with the code from #37 still works in 5.3 and the latest project and project_issue

Emery Gordon

Subscribing.

FWIW, I've been using the #46 gbear patch successfully in 5.x-1.x for quite some time. The problem with that patch was a missing comma in project_issue_perm. Haven't tested it in 5.x-2.x yet.

That solution provides the control needed for our site, but I agree that a global solution that will work for everyone is going to be a challenge. There are just too many different ways that people would want this to work, including not having it at all.

Bit updated patch works for me. Thanks.

Drupal 5.7

; Information added by drupal.org packaging script on 2008-01-07
version = "5.x-1.2"
project = "project_issue"
datestamp = "1199664009"

At the risk of adding to the myriad of options already being discussed for this topic, but here is yet another patch for your consideration.

This patch:

Edit May 2011 to fix list of permissions added by this patch.

This is a module I wipped up for an experimental proof-of-concept I was doing internally that accomplished what this issue is addressing. I haven't looked at the previous patches/module(s) posted here, but I figured I'd risk confusing things and throw this in there. It adds a maintainers sub-tab when editing a project and allows anyone with edit permission add/remove maintainers. Adding a maintainer uses a user auto-complete. Maintainers then appear in assignment drop-down in addition to anything already there for anyone with the 'assign to maintainer' permission.

I haven't released this on d.o -- but if there's interest, let me know and I will.

Edit: This was made against 2.0 as well

I'm definitely interested ! I use the project module to manage projects involving rather small teams (<20 people). Ability to dispatch bugs and feature request between team members is a "must have".

I am trying to use your module but the maintainers I add don't appear in the "Assigned :" select box of the issue form.
I have all necessary permissions (assign to maintainer).

Did I miss something ?

In our use case we didn't need the names to appear in the main node form, just in the comment form with project_issue 2.0. The code as it is won't add names to the node form (seen when creating an issue or editing the issue node directly). I haven't heard anything before now on whether or not there's interest. For now, I'll see about wrapping it into a releasable module and including the names on the main issue node form.

http://drupal.org/project/project_maintainers

I think this should really be integrated into the project_issue module, even if it's an optional feature that can be toggled by the administrator for sites facing situations like d.o.

I don't think there's opposition to including this type of functionality in the project_issue module itself, but the problem is that there are about 100 use cases for this kind of feature, and how do we provide this functionality without making it either completely inflexible or terribly complicated. If you want code to get committed to this module, I'd take a look at comments #77 and #78 above. I haven't looked in detail, but it seems like the most recent patches here are not based on the ideas brought up in #77 and #78. If there's a good reason then feel free to explain why your way is better.

I took what you said to heart, aclight, and took a look at the previous patches and the comments you pointed out. I like very much the idea of having project_issue provide a hook that other modules can easily implement without going the route of form_alter. Here's a very simple patch which adds a hook_issue_assignees() as suggested in #77.

Note for those looking for a solution that this module does not change the user-perceived behavior of the module, but rather will allow other modules to easily add users to the list of possible assignees.

For discussion: This patch only allows modules implementing the hook to add names to the list -- should they also be able to modify/delete entries in the list?

Couldn't you pass $assignees to the functions that implement this hook and make those functions take $assignees by reference? That way, they could add/alter/delete names from the list.

Yep, that's what I was thinking. Wanted to know if others generally liked that approach or not. Here's a patch applying your suggestion.

i *think* we want the hook to be hook_project_issue_assignees(), which is slightly longer, but more self-documenting.

also, please use $function instead of $func -- we generally don't abbreviate variables that way.

toss in a period at the end of your code comment, and i think we're getting somewhere... :)

one other thing: are we sorting the $assigned array at all before we send it to the form code? it would be quite a mess to navigate the list if not...

• refactored to hook_project_issue_assignees()
• code cleaned up per recommendation
• list is now alphabetically sorted, with Unassign/Unassigned listed first

hrm. wouldn't it be a bit cleaner to call the hook first, then prepend the unassigned item?

I did as you suggested and also moved code adding the name for the currently-assigned person to project_issue's implementation of hook_project_issue_assignees().

i don't think asort() is what we want.

try http://us3.php.net/natcasesort

Switched to natcasesort() instead of asort()

code looks good. tested, and seems to work perfectly.

there is one more thing that would be nice, though. and that is documentation for the hook. since we have no general hook documentation for project* at this time, i think it would be serviceable to put the relevant documentation on project_issue_project_issue_assignees().

so add some doxygen to that function, and make sure you include enough detail so that somebody reading the function doc can figure out what the args do, and how to use the hook.

thanks for your persistence -- this is looking good.

Okay, I put in some documentation. Let me know if the documentation makes sense.

I've really enjoyed this process, and once we get this hammered out, I'm looking forward to trying to contribute more.

Fixed minor typo in documentation

The patch has windows line endings and appears to have been rolled against something other than pi HEAD, so here's an updated patch with those things fixed.

attached cleans up the logic used in project_issue_project_issue_assignees()

• uid 0 is always used for the 'unassign' option, so we should only perform any operations if an auth user is logged in
• if a new issue it being created, then skip the addition of the currently assigned user

Tested functionality and it works well. And patch really does not have windows line endings this time :)

I've attached a testing module that can be used to test this patch. The module adds all users in the {users} table as potential assignees. This is just for testing the patch, not production use.

test module works as advertised. this is ready IMO. committed to 5.x-2.x, deployed on d.o.

setting back to active, so that we can include any other assignees options we want in project_issue_project_issue_assignees().

Hi, I've tested this and it works, I have one request/improvement... I have created a role "developers" it would be more useful if it were possibe to choose a role type to select assignees/users from.

Otherwse this little addition is great.

Thanks, Ryan

in the 2.1 version of this module i can find the hook_project_issue_assignees. but in 2.2 it is gone again. what happened to it?

@ Johnny vd Laar: It's still there. The call from issue.inc that invokes the hook is at line 720 in http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project_iss... and the actual implementation of the hook in the project_issue module is in that same file at line 984.

ok thx i think something went wrong with writing permissions then on our server and i'm still looking at the old file ;(

Is there a way of adding the assigend person to views. I want to be able to create a view to show the developers what their current issues list is. The assigned field is not an available field or filter in views.

Kind regards,

Ryan

@rwbgb: Project issue does not yet include support for views, so no, this is not yet possible. However, there is a patch for the D5 version of project issue at #76725: Refactor project issue module to use Views that does expose the assigned field to Views. Testing/reviews of that patch would be appreciated.

attached implements the 'assign and be assigned project issues' perm in the project issue module itself. this is a simple permission that allows any user with the perm to assign project issues to any other user with the perm.

i think this will be all for the stock assignee stuff in project issue, at least as far as this issue is concerned.

and the patch