On , Bohuslav Kabrda wrote:
----- Original Message -----
So I would like to propose: / > home /coprs/ > list all the repos (same as home, atm) /coprs/<user>/ > list someone's copr /coprs/<user>/<repo>/ > the detail of this copr /coprs/<user>/<repo>/{permissions,builds,...}/ > same as now the permissions, builds or other page for this repo (the repo file for yum could end up here as /coprs/<user>/<repo>/repo/ )
I've been thinking about this for a long time and this is why I decided to not take your proposed way: Since Copr doesn't have control over user names (it takes them from FAS, currently), we cannot prevent user named e.g. "new" or "edit" to register. Since "new" and "edit" are also keywords (/coprs/new/, /coprs/edit/) accessed by GET, this would result in an ugly URL collision (either user's coprs list would be unaccessible or noone would be able to display the "new copr" page).
Does that make sense or have I missed something?
Hi Slavek,
Indeed, I was missing these two cases. I thought of two approaches:
change the URLs pattern: - /coprs_new/ - /user_edit/ I'm not big fan of this approach (but it's one)
Incorporate the username in the URL: - /coprs/<user>/new - /coprs/<user>/edit <- (this is the edit page of the user prefs right?, otherwise it should be /coprs/<user>/<repo>/edit)
Since we have the hand on the repos creation we can blacklist "edit" and "new" as copr name and since a user have to be logged in to access the new or edit pages we can generate these URLs.
I like this approach more than the previous but, it's a bit of thinking out loudly here, I'm not sure this is the best solution
Best regards, Pierre