* Added functionality for administrators to directly add users to the
application
* Added permission users:create:any to handle level that users are
allowed to create other users
* Moved old permission users:create to users:create:self
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.
Michael Serajnik