Closed (fixed)
Project:
Project issue tracking
Version:
7.x-2.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
21 Oct 2012 at 22:41 UTC
Updated:
4 Jan 2014 at 02:42 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dwwMost of the code to do this is working, but the theme function we're using isn't being properly registered with the theme registry, which is why no output is getting injected. I'll fix that, stay tuned.
However... this raises an interesting problem, much like #1801566: Add a project creation landing page. In theory, there are now multiple node types that could be issue nodes. So where does this 'create new issue' link send you? Just going to node/add is a bit sucky, especially since in the vast majority of cases, we only have a single issue node type. A few options:
A) Add a magic issue creation landing page along the lines of what we're talking about at #1801566.
B) When constructing this link, have a little logic to check what node type(s) are configured to be issues. If N == 1, go directly to node/add/X, if N>1, just go to node/add and punt.
C) Always just link to the default issue node type we ship with project_issue.
D) other?
Thoughts?
Thanks,
-Derek
Comment #2
dwwThis fixes the theme function badness. Still 'needs work' since it's not yet clear where the 'Create a new issue' link should send you.
Hrm, this also appears to be broken insofar as the project-specific views aren't passing their project arg down to the args like we used to have in D6.
Comment #3
dwwThis fixes the views argument bug and ports the logic in project_issue_query_result_links() to the D7 approach of various stuff (e.g. field_project_machine_name), etc.
Only needs work to decide what to link 'Create a new issue' to...
Comment #4
senpai commentedSince we know that A) We're in an issue queue that belongs to a parent project node (which already exists and has a type), that relationship has been defined. B) We know that there are already issue nodes of a certain type in this queue and thus that relationship has also been defined. Why then can we not simply deduce that we'd like to make another node of the type that goes with the project we're in?
Or, are you saying that we don't yet *have* a 1-to-1 relationship between a project node type and an issue node type which belongs to that project node? If that's the case, we should start there. :)
Comment #5
dwwRight, there's no 1-1 relationship between project node types and issue node types. You could certainly imagine wanting a different node type for core issues from contrib issues, so tying the issue node type to the project node type could make sense. But, you could also imagine wanting different fields on bug reports than on feature requests, and especially between either of those and support requests. That was the kind of thing we had in mind for different issue node types. But, the point of building this as a flexible system is that people are going to end up using it in ways we don't necessarily expect or know in advance. So I don't want to be making any assumptions about this sort of thing.
Furthermore, these links exist at pages that don't already have a project specified, e.g. https://drupal.org/project/issues. In that case, the create link sends you to the "first pick a project" landing page.
However, in the interest of time, the simplest approach for now is probably B. I can code up a little helper function to render a 'Create an issue' link that takes an optional project argument. For now, it just checks all the node types that are configured to be issue nodes. If there's only one such node type (which will be true for the initial launch on d.o), we link directly to that. Otherwise, we just send you to node/add. For now. We can revisit this after launch and make it slicker before the 7.x-2.0 release.
Comment #6
senpai commentedOk, that's awesome future logic, and I love it's power, but for now, why couldn't we allow site admins to define a "default" node type for their project's issue queue, and have the 'add new issue' link(s) use that? If it's not admin-defined, then we default to the one initial 'project_issue content type (like we have on d.o). [yes, reading back over this, it's exactly what you said in #5 above :]
Then, later on down the road, if an admin has defined more than one content type for their project's issue queue, they can leverage an as yet to be created UX that asks the user what type of issue they'd like to create (bug, task, feature request, etc.) and then routes them to the appropriate node/add/project_issue_* form.
Comment #7
dwwOk, this one includes a project_issue_get_create_link() helper function along the lines of what I proposed above. Seems to be working fine on a site with only one issue node type. ;) Once I added a 2nd node type that was configured to behave like an issue, it just links directly to node/add without specifying a bundle nor the optional project argument. We probably need better before a 7.x-2.0 release, but not a d.o D7 launch.
Comment #8
dwwMoved the follow-up cleanup for sites with more than 1 issue node type to #1822482: Deal with 'create an issue' links for sites with more than 1 issue node type. Committed this, pushed to 7.x-2.x, and deployed on git7site.
Behold: http://git7site.devdrupal.org/project/issues/views