The bug could be reproduced as follows:
1. Navigate to /posts
2. Search for "test"
3. Navigate to /posts again
4. Refresh the page
The user should see plain post list, but instead they were seeing the
"test" search results again as if step 3 never happened.
Print all links through new uri.js component
Refactor the router to use more predictable parsing
Fix linking to entities with weird names (that contain slashes, + etc.)
In the post list, when we navigate to the page with ">" button, we
navigate to older posts.
In the post view, when we navigate to the page with ">" button, we
navigate to older posts as well.
However, in the post list, the ">" button is called "next page".
At the same time, in the post view, the ">" button was called "previous
post". Now it's called "next post".
The difference isn't visible to normal users nor even API consumers as
the "get posts around post X" request isn't documented.
The change is motivated not only by consistency, but to also improve
compatibility with Vimperator's `[[` and `]]`. Vimperator assumes the
word "next" refers to ">" and the word "previous" refers to "<".
Visiting mass-tag URL directly ignored masstag privileges and showed
tag/untag controls (although didn't show the controls in the header).
After this change, bypassing mass tag privileges got a little bit
harder. (It's still possible for the user to talk directly to the API
after all.)
In other words, verify the privileges client-side before issuing an
request to the server. This commit focuses on routing (e.g. clicking a
link while not logged in), rather than DOM element visibility that
should be already taken care of.
- Hide fields that are uneditable, rather than disabling them
- Support fragmented edit privileges (e.g. roles than can edit only some
aspects of tags) - up until now the client tried to send everything at
once, which resulted in errors for such cases.
