Thanks Bert, it all makes sense now. Is there a curl command one could use to manually view the metadata and/or content of earlier versions for support purposes?
= nate On Sep 11, 2012, at 2:18 AM, Bert Pareyn <[email protected]> wrote: > Hi Nate, > > The _previousVersion value has never been used to determine the version > order. Instead we use the '1.20' notation you'll see coming back in the feed > as well. > Only 25 items returning without an option to page is a backend bug and I > created a ticket for it at KERN-3168. > We probably still want to limit the feed to 25 items but make the UI able to > page through the versions. > > Hope that helps, > - Bert > > On 11 Sep 2012, at 02:10, Nate Angell <[email protected]> wrote: > >> Bert/Mark: >> >> Following up on your earlier versions curiosity posts ;) >> >> Do either of you know how to view what I'm thinking are "hidden" >> versions of a sakaidoc? >> >> For example, a URL like >> https://domain.tld/p/m5g95Ejui/id1995724.versions.json >> >> Returns what looks like the most recent 25 of 37 total saved versions, >> as per below. I'm trying to view versions 1.11 and previous. I see >> that v1.12 has _previousVersion of c2AqMPeXEeGwBzG0CjQLZA+, but I >> can't figure out how to get to it. >> >> { >> "items": >> 25, >> "path": >> "m5g95Ejui/id1995724", >> "total": >> 37, >> "versions": >> { >> "1.12": >> { >> "_created": >> 1346787259428, >> "_createdBy": >> "User", >> "_id": >> "gyBMwPeXEeGwBzG0CjQLZA+", >> "_lastModified": >> 1346876590893, >> "_lastModifiedBy": >> "User", >> "_nextVersion": >> "iWKgEPeXEeGwBzG0CjQLZA+", >> "_path": >> "m5g95Ejui/id1995724", >> "_previousVersion": >> "c2AqMPeXEeGwBzG0CjQLZA+", >> "_readOnly": >> "Y", >> "_versionHistoryId": >> "isyt4PbHEeGqNrbsCjQLZQ+", >> "_versionNumber": >> 1346876601489, >> "page": >> "<p>content<\/p>", >> "versionId": >> "gyBMwPeXEeGwBzG0CjQLZA+" >> }, >> "1.13": >> { >> etc... >> >> = nate >> >> On Wed, Jun 6, 2012 at 2:38 AM, Mark Triggs <[email protected]> wrote: >>> Hi Bert, >>> >>> Yep, exactly--that neatly summarises what I'm seeing. If this is the >>> expected behaviour then I'm happy and can work with it. >>> >>> Thanks, >>> >>> Mark >>> >>> >>> Bert Pareyn <[email protected]> writes: >>> >>>> Hey Mark, >>>> >>>> If I'm reading this correctly I'd say this is expected behaviour. >>>> From the moment you upload a new version the data that's set on the >>>> current version will be stored, the data that's set after that upload will >>>> not be applied to that created version. >>>> Further break down of your workflow: >>>> >>>> - Upload new version through add content widget, creates version 1.0 and >>>> sets the description to 'V1'; >>>> - Upload second version, this takes description 'V1' and creates version >>>> 1.1. Afterwards you change the description to 'V2'; >>>> - Upload a third version, this takes description 'V2' and applies it to >>>> 1.2. >>>> >>>> Results: >>>> >>>> - 1.0 has description of V1 >>>> - 1.1 has description of V1 >>>> - 1.2 has description of V2 >>>> >>>> So, in short, users would have to change their description to 'V2', 'V3', >>>> etc. prior to uploading a new version. >>>> >>>> Hope to help (and make sense) >>>> - Bert >>> >>> -- >>> Mark Triggs >>> <[email protected]> >>> _______________________________________________ >>> oae-dev mailing list >>> [email protected] >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
