modules/user/views/admin_users.html.php

<?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_form/<?= $user->id ?>" class="gDialogLink"><?= _("edit") ?></a>
        <? if (!(user::active()->id == $user->id || user::guest()->id == $user->id)): ?>
        <a href="users/delete_form/<?= $user->id ?>" class="gDialogLink">
          <?= _("delete") ?></a>
        <? endif ?>
      </li>
      <? endforeach ?>
      <li><a href="users/add_form" class="gDialogLink" title="<?= _("Add user") ?>">
        <?= _("Add user") ?></a></li>
    </ul>
  </div>
</div>
Change the preamble for views in two ways: 1) drop unnecessary semicolon 2) start with <?php for extra security in the case that the server itself doesn't have short_tags enabled (the app won't work, but we need to make sure that we're still secure) 2009-01-01 00:23:29 +00:00			`<?php 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">`
User/Group administration cleanup 2008-12-26 06:14:24 +00:00			`<h2><?= _("User Administration") ?></h2>`
refactored admin views and added 'List User' 2008-12-14 07:59:24 +00:00			`<div class="gBlockContent">`
User/Group administration cleanup 2008-12-26 06:14:24 +00:00			`<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) . ")" ?>`
Fix up all the various little forms to have submit buttons, fieldset legends, etc etc. 2009-01-06 09:22:29 +00:00			`<a href="users/edit_form/<?= $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)): ?>`
Fix up all the various little forms to have submit buttons, fieldset legends, etc etc. 2009-01-06 09:22:29 +00:00			`<a href="users/delete_form/<?= $user->id ?>" class="gDialogLink">`
Added title to user/group administration dialogs 2008-12-26 20:34:56 +00:00			`<?= _("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 ?>`
Added title to user/group administration dialogs 2008-12-26 20:34:56 +00:00			`<li><a href="users/add_form" class="gDialogLink" title="<?= _("Add user") ?>">`
			`<?= _("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>`