Especially once #539282: Denormalize release info a bit and store latest and recommended releases in {project_release_supported_versions} lands, this will be a key element of completing #76726: Refactor project module to use Views [meta issue]. It will allow us to do lots of fancy release-related views, including the release download table (both for embedding on project nodes, and for embedding as a field in project browsing views).

Comments

dww’s picture

Status: Active » Needs work
StatusFileSize
new5.28 KB

Sort of working. ;) The only snag is that it doesn't yet properly JOIN using {prsv}.tid, since that's a pain. For the Nth time, I wish we just had a denormalized copy of tid in {project_release_nodes}. So, let's do that. ;) #540074: Denormalize release API compatibility tid into {project_release_nodes}

This also doesn't yet touch the data from #539282: Denormalize release info a bit and store latest and recommended releases in {project_release_supported_versions}, but that should be easy to add once that patch lands. We can just keep using this issue for that followup task.

dww’s picture

This is a lot closer. Depends on #540074: Denormalize release API compatibility tid into {project_release_nodes} and almost takes full advantage of #539282: Denormalize release info a bit and store latest and recommended releases in {project_release_supported_versions}. However, the custom filter handler is bogus, since it's hard-coding "node.nid" into the query it constructs. I need to check with merlinofchaos on the right/elegant way to accomplish this...

Also, not positive if I want separate filters for latest and recommended, or if those should be merged into a single filter, so you could, for example, expose it and let folks select which one they want to see... Might simplify the views UI a bit to have a single filter with options, instead of completely separate filters.

dww’s picture

Status: Needs work » Needs review
StatusFileSize
new9.08 KB

Since I woke up and Earl seems to be AFK, I did some investigation myself. Seems like the right approach for #2 is the following:

  $base_nid = $this->query->base_table . '.' . $this->query->base_field;
  $this->query->add_where($this->options['group'], "$this->table_alias.$this->real_field " . $this->operator . " $base_nid");

See attached patch. Still not sure about 1 filter or two, but calling this "needs review" for now...

dww’s picture

Status: Needs review » Needs work

As expected/feared, once I got Earl to look, he told me #3 isn't relationship-safe. ;) Re-rolling now...

dww’s picture

Merged into a single filter with a UI to select which field you want. Still not relationship-safe, but we're almost there.

dww’s picture

Status: Needs work » Needs review
StatusFileSize
new14.34 KB

Huzzah. Finally got something relationship-safe and working.

dww’s picture

Status: Needs review » Fixed

After a bit more testing, committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.