We already support sort=last_updated, alpha or random. Mark previously suggested registration date (I don't think this field is present, you can sort by "_id" and that will be good enough).
Could you clarify this ticket? I have started by creating navigation menu just below 'Categorization' at http://localhost:8080/p/admin/ In that view I planned to have several options that could be chosen: "Last Updated", "Last Registred", and "Alphabetically". Now, I am not sure this is what is required. Could you guide me a little more?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And here's an example with more parameters [[projects sort=random limit=8 display_mode="list"]] The code is in allura/lib/macro.py
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-03-23
Originally by: *anonymous
42cc corresponding ticket - #12: [3927] Project list sorting (2cp)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-03-23
Originally by: *anonymous
Fixed #12: 3927 Project list sorting (2cp) - pushed changes into 42cc_3927 branch. I've tried to rebase it but with no success - lots of merge conflicts :/. If it's really necessary I'll try to do this later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We actually have some tests for the [[projects]] macro already in Allura/allura/tests/test_globals.py (def test_macros) I grepped for [[projects to find them. Can you update the tests to be alongside the other similar ones in test_globals.py?
There's a typo in "last_registred" Should be "last_registered"
Rebasing would be tricky because this branch was based off of the 42cc branch which is pretty messy. I think it'll be simpler if future branches are based off of the latest "dev". And in that case you won't have to worry about rebasing, I can do it when I merge it back to dev.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-03-26
Originally by: *anonymous
OK, we'll fork future branches for next tickets from your dev-branch.
Now we've created a branch from our master, which contains all the code we've already written before and merged with your current dev-branch (we merge changes from a ticket to the master branch when the ticket is closed). Then, when everything's ready I merge our master into 42cc branch and push it to Allura. The same is for our #11 ticket. We need Makefile for our barista which was not present in dev branch before, so we did it this way...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally by: dudarev
Could you clarify this ticket? I have started by creating navigation menu just below 'Categorization' at http://localhost:8080/p/admin/ In that view I planned to have several options that could be chosen: "Last Updated", "Last Registred", and "Alphabetically". Now, I am not sure this is what is required. Could you guide me a little more?
[[projects]]is a wiki macro that you can use on neighborhood-level wiki pages. Here are a few live examples:And here's an example with more parameters
[[projects sort=random limit=8 display_mode="list"]]The code is in allura/lib/macro.pyOriginally by: *anonymous
42cc corresponding ticket - #12: [3927] Project list sorting (2cp)
Originally by: *anonymous
Fixed #12: 3927 Project list sorting (2cp) - pushed changes into 42cc_3927 branch. I've tried to rebase it but with no success - lots of merge conflicts :/. If it's really necessary I'll try to do this later.
We actually have some tests for the
[[projects]]macro already in Allura/allura/tests/test_globals.py (def test_macros) I grepped for[[projectsto find them. Can you update the tests to be alongside the other similar ones in test_globals.py?There's a typo in "last_registred" Should be "last_registered"
Rebasing would be tricky because this branch was based off of the 42cc branch which is pretty messy. I think it'll be simpler if future branches are based off of the latest "dev". And in that case you won't have to worry about rebasing, I can do it when I merge it back to dev.
Originally by: *anonymous
OK, we'll fork future branches for next tickets from your dev-branch.
Now we've created a branch from our master, which contains all the code we've already written before and merged with your current dev-branch (we merge changes from a ticket to the master branch when the ticket is closed). Then, when everything's ready I merge our master into 42cc branch and push it to Allura. The same is for our #11 ticket. We need Makefile for our barista which was not present in dev branch before, so we did it this way...