modules/user/views/admin_users.html.php

<? defined("SYSPATH") or die("No direct script access."); ?>
<div class="gBlock">
  <h2>User Administration</h2>
  <div class="gBlockContent">
    <p>These are the users in your system</p>
    <ul>
      <? foreach ($users as $i => $user): ?>
      <li>
        <?= $user->name ?>
        <?= ($user->last_login == 0) ? "" : "(" . date("M j, Y", $user->last_login) . ")" ?>
        <a href="users/edit/<?= $user->id ?>" class="gDialogLink">edit</a>
        <? if (!(user::active()->id == $user->id || user::guest()->id == $user->id)): ?>
        <a href="users/delete/<?= $user->id ?>" class="gDialogLink">delete</a>
        <? endif ?>
      </li>
      <? endforeach ?>
      <li><a href="users/add/<?= $user->id ?>" class="gDialogLink">Add user</a></li>
    </ul>
  </div>
</div>
Add proper preamble 2008-12-15 01:49:15 +00:00			`<? defined("SYSPATH") or die("No direct script access."); ?>`
refactored admin views and added 'List User' 2008-12-14 07:59:24 +00:00			`<div class="gBlock">`
			`<h2>User Administration</h2>`
			`<div class="gBlockContent">`
			`<p>These are the users in your system</p>`
User Administration. Edit users. Take 3 2008-12-26 00:58:15 +00:00			`<ul>`
Implement admin user editing. It's still very rough. Trying to figure out how to share forms between user and admin editing. Incremental improvement 2008-12-19 22:16:10 +00:00			`<? foreach ($users as $i => $user): ?>`
Big round of normalization of the way that our controllers communicate. Almost all controllers now use JSON to speak to the theme when we're dealing with form processing. This means tht we only send the form back and forth, but we use a JSON protocol to tell the browser success/error status as well as the location of any newly created resources, or where the browser should redirect the user. Lots of small changes: 1) Admin -> Edit Profile is gone. Instead I fixed the "Modify Profile" link in the top right corner to be a modal dialog 2) We use json_encode everywhere. No more Atom/XML for now. We can bring those back later, though. For now there's a lot of code duplication but that'll be easy to clean up. 3) REST_Controller is no longer abstract. All methods its subclasses should create throw exceptions, which means that subclasses don't have to implement stubs for those methods. 4) New pattern: helper method get_add_form calls take an Item_Model, not an id since we have to load the Item_Model in the controller anyway to check permissions. 5) User/Groups REST resources are separate from User/Group in the site admin. They do different things, we should avoid confusing overlap. 2008-12-25 05:12:46 +00:00			`<li>`
			`<?= $user->name ?>`
			`<?= ($user->last_login == 0) ? "" : "(" . date("M j, Y", $user->last_login) . ")" ?>`
User Administration. Edit users. Take 3 2008-12-26 00:58:15 +00:00			`<a href="users/edit/<?= $user->id ?>" class="gDialogLink">edit</a>`
Big round of normalization of the way that our controllers communicate. Almost all controllers now use JSON to speak to the theme when we're dealing with form processing. This means tht we only send the form back and forth, but we use a JSON protocol to tell the browser success/error status as well as the location of any newly created resources, or where the browser should redirect the user. Lots of small changes: 1) Admin -> Edit Profile is gone. Instead I fixed the "Modify Profile" link in the top right corner to be a modal dialog 2) We use json_encode everywhere. No more Atom/XML for now. We can bring those back later, though. For now there's a lot of code duplication but that'll be easy to clean up. 3) REST_Controller is no longer abstract. All methods its subclasses should create throw exceptions, which means that subclasses don't have to implement stubs for those methods. 4) New pattern: helper method get_add_form calls take an Item_Model, not an id since we have to load the Item_Model in the controller anyway to check permissions. 5) User/Groups REST resources are separate from User/Group in the site admin. They do different things, we should avoid confusing overlap. 2008-12-25 05:12:46 +00:00			`<? if (!(user::active()->id == $user->id \|\| user::guest()->id == $user->id)): ?>`
User Administration. Edit users. Take 3 2008-12-26 00:58:15 +00:00			`<a href="users/delete/<?= $user->id ?>" class="gDialogLink">delete</a>`
Big round of normalization of the way that our controllers communicate. Almost all controllers now use JSON to speak to the theme when we're dealing with form processing. This means tht we only send the form back and forth, but we use a JSON protocol to tell the browser success/error status as well as the location of any newly created resources, or where the browser should redirect the user. Lots of small changes: 1) Admin -> Edit Profile is gone. Instead I fixed the "Modify Profile" link in the top right corner to be a modal dialog 2) We use json_encode everywhere. No more Atom/XML for now. We can bring those back later, though. For now there's a lot of code duplication but that'll be easy to clean up. 3) REST_Controller is no longer abstract. All methods its subclasses should create throw exceptions, which means that subclasses don't have to implement stubs for those methods. 4) New pattern: helper method get_add_form calls take an Item_Model, not an id since we have to load the Item_Model in the controller anyway to check permissions. 5) User/Groups REST resources are separate from User/Group in the site admin. They do different things, we should avoid confusing overlap. 2008-12-25 05:12:46 +00:00			`<? endif ?>`
			`</li>`
Implement admin user editing. It's still very rough. Trying to figure out how to share forms between user and admin editing. Incremental improvement 2008-12-19 22:16:10 +00:00			`<? endforeach ?>`
User Administration. Edit users. Take 3 2008-12-26 00:58:15 +00:00			`<li><a href="users/add/<?= $user->id ?>" class="gDialogLink">Add user</a></li>`
Edit user - first draft 2008-12-23 21:44:35 +00:00			`</ul>`
refactored admin views and added 'List User' 2008-12-14 07:59:24 +00:00			`</div>`
			`</div>`