provide a "show_user_profiles_to" setting to allow admins to open it
up to everybody (choices there are "registered_users", "admin_users"
or "everybody"). Fixes ticket #1378.
by the following rules:
1) An initial dialog or panel load can take either HTML or JSON, but
the mime type must accurately reflect its payload.
2) dialog form submits can handle a pure HTML response, but the mime
type must also be correct. This properly resolves the problem
where the reauth code gets a JSON response first from the reauth
code, and then an HTML response when you reauth and continue on to
a given form -- try it out with Admin > Settings > Advanced.
3) All JSON replies must set the mime type correctly. The json::reply
convenience function does this for us.
4) By default, any HTML content sent back in the JSON response should be
in the "html" field, no longer the "form" field.
The combination of these allows us to stop doing boilerplate code like
this in our controllers:
// Print our view, JSON encoded
json::reply(array("form" => (string) $view));
instead, controllers can just return HTML, eg:
// Print our view
print $view;
That's much more intuitive for developers.
"display_all" is too coarse, and we should be letting event handlers
make the appropriate decision on what to display and when. This
duplicates some code, but it's now very clear in the event handlers
what's getting shown.
Throw a 404 if we try to view the user profile for a missing user.
The only feature change in this should be that we now display the
name, full name and website for a user to any other registered user,
which makes sense since these are typically public fields.
Don't show any of the edit buttons unless identity::is_writable()
