Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Please remove the "assigned to" on issue links ([#number]) or give me a way to do it. I really, really, really, really, really don't want that there. I have gone back and removed my name from issues to get rid of it.
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 367423-21.optional_assigned.d6.patch | 8.46 KB | dww |
| #21 | 367423-21.optional_assigned.png | 10.27 KB | dww |
| #19 | 367423-19.optional_assigned_bluebeach.d5.patch | 3.4 KB | dww |
| #19 | 367423-19.optional_assigned.d5.patch | 8.08 KB | dww |
| #19 | 367423-19.optional_assigned.d6.patch | 8.43 KB | dww |
Comments
Comment #1
VM CreditAttribution: VM commentedI think more than a few maintainers use that as a tool. If so, I don't think removing it across the board is the way to go.
I'd think to get something like that altered or get a field to be able to be hidden would require more of an argument than really really really really really really not wanting it there.
Comment #2
VM CreditAttribution: VM commentedDidn't mean to change the component, though I'd think at this stage it would have to be done in redesign so I'm leaving it.
Comment #3
Gábor HojtsyThe feature was introduced in http://drupal.org/node/360936 and is already in use by core maintainers and others, as described at http://hojtsy.hu/blog/2009-jan-23/selfmade-project-planning-tools-drupalorg
Comment #4
NancyDruI used to use it on modules that I co-maintain, but I hate seeing it in the links ([#xxxx]). I only want to see it on the issues page where the others can see that I'm working on a particular issue. So now I will stop using that field entirely unless there is some way to turn it off.
Comment #5
dwwI'm actually in favor of removing these, too. I think it just adds way too much noise in the common case, for the benefit of an edge case.
Comment #6
aclight CreditAttribution: aclight commentedWhat about not displaying the assigned to part in issues but keep it when it is in other types of nodes (like the book nodes used during the sprint)?
Comment #7
dww@aclight: that seems like a good compromise. i'd be in favor of that if it's technically easy. However, doesn't the filter cache make that difficult?
Comment #8
NancyDruI'm guessing that Gábor and other core developers will push back on this. Interesting, Derek, I would have guessed that you wrote that code.
Comment #9
aclight CreditAttribution: aclight commentedI don't mind the assigned to part on web pages, but it's really annoying in emails, since it's not demarcated from the text at all as it is with the background in the web page.
@dww: Isn't the filter cache per node? In other words, content on one node would have a separate entry in the filter cache from a different node. Or is your point that the filter itself might not know what type of node it is being used in, and therefore it would not be possible to produce different results depending on the node type calling the filter?
Comment #10
NancyDruThe filter module is not called with the node; it is called with the text. So identical text in different nodes could use the same cache entry, although that is highly unlikely. But, absent some other passed parameter, the node type is not available to Filter functions.
Comment #11
dwwRight, and this code is actually showing up via a theme function that controls what this filter text is replaced by, and I don't know if that theme function gets enough context to do the right thing.
Yes, it's also very annoying in emails...
dare I suggest a different syntax if you really need "Assigned to" to show up? It seems like only a very tiny minority of use-cases for this filter wants that extra stuff.
Comment #12
NancyDruThat would work for me. Something like [$1234]?
Comment #13
dwwIf we were going to do a new syntax (which is still a big if) I think something like this would be more clear:
[#xxxxxx@]-- it's just like [#xxxxxx] except you have the person @ the end.However, that'd be a lot more work, since it'd involve changing the regexp for the filter itself, having separate theme functions for w/ and w/o the @, etc, etc.
Is it really critical for the cases where it's used in book pages, etc, to see assigned? Can we revert that much (and keep the coloration, etc) and see how that goes?
Comment #14
NancyDruAs far as I can tell, the only ones that want it are the core folks, and I doubt they are using it in many book pages.
It wouldn't matter to me if I had to start putting the "@" to get rid of the "assigned to." That might make it easier on the core folks, who already have their hands full with D7. I would prefer to keep being able to assign issues when there are multiple maintainers, but I don't like that "assigned to" in my issue cross-refs, project pages, and release notes.
Comment #15
dwwIt seems like there are only a small handful of places where the "assigned" stuff is appropriate, namely book pages where you specifically want this info. Therefore, it should be opt-in. The fact that the "core maintainers are busy" has nothing to do with it, and typing 1 extra character for this will hardly be the straw that breaks anyone's back. ;) It'd only be a one-time cost for someone(s) to go through http://drupal.org/community-initiatives and add "@" where appropriate, and certainly none of the core maintainers would have to do that themselves.
Attached patches for D5 and D6. This also moves this feature entirely back into project* so we don't have to maintain as much custom code in bluebeach. For example, none of this stuff is ported into the trunk copy of bluebeach in the *.d.o SVN repo.
Now deployed on p.d.o for testing (don't forget to clear your browser cache):
http://project.drupal.org/node/343023
Any objections?
Comment #16
dwwThere was a bug in the D5 backport for the hover attribute. This fixes it (also updated on p.d.o).
That reminds me, as another compromise, we could put the assigned info in the hover title attribute if @ isn't used. Thoughts on that?
Comment #17
Gábor HojtsyFine for me. Before it can be deployed in Drupal.org (if on Drupal 5), we need a patch against bluebeach too.
Comment #18
aclight CreditAttribution: aclight commentedI was thinking of having the assigned part in the title attribute as well. That's the best of both worlds--for the web pages it's available but not obtrusive, and in email it's not there at all.
Comment #19
dwwHere's the patch against bluebeach, and patches for D5 and D6 that puts "Assigned to: !username" in the title attribute if it's assigned to someone and @ isn't present. Any remaining objections?
Comment #20
NancyDruCan I make one little bitty request? Please use
theme('username',...).Comment #21
dww@NancyDru: That should be a followup feature request.
a) I don't want to hold this up any longer for feature creep.
b) I'm not sure it's a good idea (linking to the user might not make the most sense).
c) It'd require some more CSS mojo to look right (see attached patch).
Comment #22
NancyDruOkay, you're the boss. However it is possible to prevent the linking by unsetting the uid.
Comment #23
dwwthen what's the point of theme('username')?
Comment #24
dwwCommitted to HEAD and DRUPAL-5--2 of project_issue, to the drupal/themes/bluebeach/branches/5 branch in SVN, deployed on d.o, and filter cache cleared. I also edited a handbook page to see this code working in action:
http://drupal.org/node/362117/revisions/view/422748/429828
Comment #25
NancyDruProject is not only used on DO. Using theme_username makes it work right with RealName.
Thanks for this change; you're a gem.
Comment #26
dww@NancyDru: as I said, I'm not fundamentally opposed, I just don't want to deal with it here. ;) If you want to open a new feature request for this, please do...
Comment #27
dwwMoving this back to the right queue -- this is now a feature in project_issue itself, not a d.o-specific change.
Comment #28
dwwComment #29
NancyDruBTW, thank you very much for this.
Comment #30
dwwGladly. :) This was definitely a case of scratching my own itch... ;)
Cheers,
-Derek
Comment #31
Dave ReidWas this fix actually deployed to d.org, because the filter tips have not been updated at all. I can't link to specific comments by using [#issue_id-comment_id].
Comment #32
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedJust testing. :)
#367423: Make "assigned to" on issue links opt-in (by appending '@'): #367423: Make "assigned to" on issue links opt-in (by appending '@')#367423: Make "assigned to" on issue links opt-in (by appending '@') Assigned to: dww: #367423: Make "assigned to" on issue links opt-in (by appending '@') Assigned to: dww#367423-30: Make "assigned to" on issue links opt-in (by appending '@'): #367423-30: Make "assigned to" on issue links opt-in (by appending '@')Comment #33
Dave ReidThanks. :) I was using the actual comment ID that is used in links, and not the actual comment "number" that is shown on the page. It wasn't very clear on how to do that...
Comment #34
PasqualleThe missing test case:
#367423-30: Make "assigned to" on issue links opt-in (by appending '@') Assigned to: dww: #367423-30: Make "assigned to" on issue links opt-in (by appending '@') Assigned to: dww