Bug 810960

Summary:	FEAT: catalog should support friendly make URLs
Product:	[Retired] Red Hat Hardware Certification Program	Reporter:	Rob Landry <rlandry>
Component:	Hardware Catalog	Assignee:	Pengfei Xue <pxue>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.2	CC:	hwcert-catalog, pxue, wshen
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	http://hardware.redhat.com/
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-06 05:40:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	733411

Description Rob Landry 2012-04-09 18:21:39 UTC

Description of problem:

The hardware catalog should support additional make based friendly urls.  That is to allow quick access to a particular make of system 
hardware.redhat.com/Dell/PowerEdge

hardware.redhat.com/PowerEdge

...both should take the user to the cleaner url of ...

hardware.redhat.com/Dell/PowerEdge

...which should then provide the list of Dell PowerEdge systems.

Where only a make is provided and two vendors provide that make the URL redirect is not needed.


Additional info:

It is expected with the current system that the 1st redirect happen but the end result URL is still not friendly to remember.  This issue should be resolved in a separate bz.

Comment 3 Pengfei Xue 2012-04-12 09:27:05 UTC

Created attachment 577013 [details]
new patch for friendly url

Comment 4 Rob Landry 2012-04-16 20:16:34 UTC

Test site seems to work.  Also it keeps the URL friendly.  Is this behavior expected to remain?  Does it deal with spaces properly?  Does it also deal with model names?

Comment 5 Pengfei Xue 2012-04-17 02:18:33 UTC

(In reply to comment #4)
> Test site seems to work.  Also it keeps the URL friendly.  Is this behavior
> expected to remain?  
yes, and there's no need for Apache configuration change.

> Does it deal with spaces properly?  Does it also deal with
> model names?

it can deal with spaces and underscores well

re model names support, i think this will be too fine-grained, after all, friendly url is not a query function, and many of the model names are just digits, this will mess up with ~/778223 urlrewrite which directly linking to cert#778223

or we may only support models if found vendor/make successfully, 
~/vendor/make/models, but most of the make are just vendor names, it will be too complicated.

Comment 6 Rob Landry 2012-04-25 19:20:42 UTC

(In reply to comment #5)
> (In reply to comment #4)
> > Test site seems to work.  Also it keeps the URL friendly.  Is this behavior
> > expected to remain?  
> yes, and there's no need for Apache configuration change.
> 
> > Does it deal with spaces properly?  Does it also deal with
> > model names?
> 
> it can deal with spaces and underscores well

Good news.
> 
> re model names support, i think this will be too fine-grained, after all,
> friendly url is not a query function, and many of the model names are just
> digits, this will mess up with ~/778223 urlrewrite which directly linking to
> cert#778223
> 
> or we may only support models if found vendor/make successfully, 
> ~/vendor/make/models, but most of the make are just vendor names, it will be
> too complicated.

Sorry to confuse, this was just a question.  The feature in this bug is regarding makes.

Comment 7 Pengfei Xue 2012-04-27 07:48:27 UTC

verified on web2

Comment 8 Wei Shen 2012-05-23 10:02:58 UTC

verified on partner