Closed pdelboca closed 4 years ago
If I understand correctly this has nothing to do with revision / tag listing BTW, but with showing the dataset in a given tag or revision. I think it would be nice UX if URLs accepted either a tag name or a revision sha regardless if right now we show a list of revisions anywhere in the UI. Then, to make it "just work", we can do one of a few things:
Then either:
metastore-lib can expose an API to make that guess, and then ckanext-versioning can call fetch
or tag_fetch
(IIRC the API) to get the right object, or
metastore-lib can just expose an API to get "revision or tag" given an identifier, without having the calling code having to make that distinction. It will then return either a tag or a revision object and the calling code can check what it got.
@shevron i'm +1 on @shevron point about EITHER revision ref or tag (and that this is probably something metastore lib handles). For now, we can either go with what we got and open an issue to support this later or do this now (if quick and saves us from other issues).
Ok, since this will require a little bit of I have opened #20 to implement this.
In the last PR I changed to use the
tag
as a component in the URL, this PR reverses that bad decision to keep using/dataset/xxx/show/{revref}/
as the main url schema.Note to discuss: The URL schema depends on
revision_ref
but the UI Rendering depends on tags since all elements that we show like version lists and buttons to edit are tags. This makes it a little bit confusing and we may need to do some refactor to make the whole action methods (and the overall implementation) a little bit easier to understand. Also, we cannot accesstag
viarevision_ref
directly inmetastore-lib
. Even whenbackend.fetch(...)
can receive bothtags/revision_ref
it does not return the tag metadata (name and description) that we need for the UI.