[Bps-public-commit] rt-extension-assets branch, add-tutorial, created. e45c0f9a433d69398cf34beb874c9081554d699a
Jim Brandt
jbrandt at bestpractical.com
Fri Dec 13 15:18:08 EST 2013
The branch, add-tutorial has been created
at e45c0f9a433d69398cf34beb874c9081554d699a (commit)
- Log -----------------------------------------------------------------
commit 2d9aaf8080a549c0b7213d6b230f68ede0b7a7a9
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Dec 13 14:45:39 2013 -0500
Add tutorial config and initialdata files
diff --git a/etc/Tutorial_Configuration.txt b/etc/Tutorial_Configuration.txt
new file mode 100644
index 0000000..f32772e
--- /dev/null
+++ b/etc/Tutorial_Configuration.txt
@@ -0,0 +1,24 @@
+# Configuration for the assets tutorial.
+# Copy and paste into your RT_SiteConfig.pm to test.
+
+Set(
+ $HomepageComponents,
+ [
+ qw(QuickCreate Quicksearch MyAdminQueues MySupportQueues MyReminders RefreshHomepage Dashboards SavedSearches FindUser MyAssets FindAsset) # loc_qw
+ ]
+);
+
+# Move UserAssets to the location you want on the User Summary page
+
+Set(@UserSummaryPortlets, (qw/ExtraInfo CreateTicket UserAssets ActiveTickets InactiveTickets/));
+
+# See the CustomFieldGroupings docs in RT_Config.pm for more info.
+# http://bestpractical.com/docs/rt/latest/RT_Config.html
+
+Set(%CustomFieldGroupings,
+ 'RT::Asset' => {
+ 'Asset Details' => ['Serial Number', 'Manufacturer', 'Type',
+ 'Tracking Number'],
+ 'Dates' => ['Support Expiration', 'Issue Date'],
+ },
+);
diff --git a/etc/tutorialdata b/etc/tutorialdata
new file mode 100644
index 0000000..2589e82
--- /dev/null
+++ b/etc/tutorialdata
@@ -0,0 +1,91 @@
+ at Users = (
+ { Name => 'asset-tutorial-staff',
+ RealName => 'Asset Staff User',
+ Password => 'password',
+ EmailAddress => "asset-tutorial-staff\@localhost",
+ Comments => "Sample Staff user for Assets tutorial",
+ Privileged => '1',
+ },
+ { Name => 'asset-tutorial-user1',
+ RealName => 'Asset End User',
+ Password => 'password',
+ EmailAddress => "asset-tutorial-user1\@localhost",
+ Comments => "Sample end user for Assets tutorial",
+ },
+);
+
+ at CustomFields = (
+ { Name => 'Serial Number',
+ Type => 'FreeformSingle',
+ LookupType => 'RT::Catalog-RT::Asset',
+ ApplyTo => 'General assets',
+ },
+ { Name => 'Tracking Number',
+ Type => 'FreeformSingle',
+ LookupType => 'RT::Catalog-RT::Asset',
+ ApplyTo => 'General assets',
+ },
+ { Name => 'Manufacturer',
+ Type => 'SelectSingle',
+ LookupType => 'RT::Catalog-RT::Asset',
+ ApplyTo => 'General assets',
+ MaxValues => 1,
+ RenderType => 'Dropdown',
+ Values => [
+ { Name => 'Apple', SortOrder => 1 },
+ { Name => 'Dell', SortOrder => 2 }, ],
+ },
+ { Name => 'Type',
+ Type => 'SelectSingle',
+ LookupType => 'RT::Catalog-RT::Asset',
+ ApplyTo => 'General assets',
+ MaxValues => 1,
+ RenderType => 'Dropdown',
+ Values => [
+ { Name => 'Desktop Computer', SortOrder => 1 },
+ { Name => 'Laptop Computer', SortOrder => 2 },
+ { Name => 'Server', SortOrder => 3 },
+ { Name => 'Mobile Phone', SortOrder => 4 },
+ { Name => 'Software', SortOrder => 5 },
+ { Name => 'Other', SortOrder => 6 }, ],
+ },
+ { Name => 'Issue Date',
+ Type => 'Date',
+ LookupType => 'RT::Catalog-RT::Asset',
+ ApplyTo => 'General assets',
+ },
+ { Name => 'Support Expiration',
+ Type => 'Date',
+ LookupType => 'RT::Catalog-RT::Asset',
+ ApplyTo => 'General assets',
+ },
+);
+
+push @ACL, map {
+ {
+ Right => $_,
+ GroupDomain => 'SystemInternal',
+ GroupType => 'Privileged',
+ ObjectType => 'RT::Catalog',
+ ObjectId => 'General assets',
+ }
+ } qw(ShowAsset ShowCatalog SeeCustomField CreateAsset
+ ModifyAsset ModifyCustomField);
+
+push @ACL, map {
+ {
+ Right => $_,
+ GroupDomain => 'RT::System-Role',
+ GroupType => 'HeldBy',
+ }
+ } qw(ShowAsset ShowCatalog);
+
+push @Final, sub {
+ # Update default catalog name
+ my $catalog = RT::Catalog->new(RT->SystemUser);
+ my ($ret, $msg) = $catalog->Load('General assets');
+ RT::Logger->error("Unable to load General assets catalog: $msg")
+ unless $ret;
+ $catalog->SetName('IT Department Assets');
+ return;
+};
commit a9cdf289e2b0d18ee31ea3f054fc0327b301e10c
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Dec 13 14:48:32 2013 -0500
Add tutorial document
Add as a module file to make it easier to find and link to
on metacpan.
diff --git a/lib/RT/Extension/Assets/Tutorial.pm b/lib/RT/Extension/Assets/Tutorial.pm
new file mode 100644
index 0000000..0dd2838
--- /dev/null
+++ b/lib/RT/Extension/Assets/Tutorial.pm
@@ -0,0 +1,328 @@
+
+=head1 Introduction
+
+This is a basic tutorial for setting up asset tracking in RT using Best
+Practical's Assets extension. At the end, you'll have a basic configuration
+that lets you add assets, search for them, link them to tickets, etc.
+
+=begin HTML
+
+<p><img src="http://static.bestpractical.com/images/assets/asset-search.png"
+alt="Asset Search Results" /></p>
+
+=end HTML
+
+You can follow along with the tutorial and try setting things up yourself to
+get a feel for all of the administrative controls. If you want to get a jump
+start, the files to set up this basic configuration are provided in the
+L<RT::Extension::Assets> distribution in the F<etc> directory. For
+configuration, look in F<etc/Tutorial_Configuration.txt>. You can copy all or
+part and paste it in your F<RT_SiteConfig.pm>.
+
+To load the test catalog, custom fields, and users, add
+C<RT::Extension::Assets> to your C<@Plugins> line after installing, then run
+the following from your RT directory:
+
+ sbin/rt-setup-database --action insert --datafile \
+ local/plugins/RT-Extension-Assets/etc/tutorialdata
+
+This will change the default catalog name, create some users, and give those
+users asset permissions. Only asset rights are granted, so you need to grant
+additional rights if you want to experiment with creating tickets and linking
+assets. The initial user passwords are 'password'. You should only run this on
+a test RT instance as it is not intended to be used for configuring a
+production system.
+
+=head1 Getting Started
+
+Install the extension following the instructions and some new tables will be
+added to your RT database and the assets code will be installed. As with all
+extensions, first add C<RT::Extension::Assets> to your C<@Plugins> line.
+
+There are a few configuration options you might set before starting. Assets
+offers a C<$DefaultCatalog> feature that works similar to RT's
+L<DefaultQueue|http://bestpractical.com/docs/rt/latest/RT_Config.html#DefaultQue
+ue>, but you can probably skip it for now since you don't have any catalogs yet.
+
+More interesting are some optional portlets you can activate to add asset data
+to RT's pages. MyAssets and FindAsset portlets are available for placement on
+RT at a Glance or in dashboards and a UserAssets portlet is available for the
+user summary pages.
+
+These portlets are fairly self-explanitory and you can add them by finding
+C<$HomepageComponents> and C<@UserSummaryPortlets> respectively in
+F<RT_Config.pm>, copying to F<RT_SiteConfig.pm>, and adding the portlets you
+want. There are also examples in the tutorial sample configuration file. Note
+that C<$HomepageComponents> makes the portlets available, but doesn't put them
+on RT at a Glance. To add them, just click the Edit link on the upper righthand
+corner of the homepage. C<@UserSummaryPortlets> does automatically add the
+"Assigned Assets" portlet to the User Summary page. It will appear based on the
+position in the configuration, so just place it in the list where you want it
+to appear.
+
+Once you have your configuration complete, restart your server and you're ready
+to go.
+
+=head1 Catalogs
+
+For the initial configuration, we'll log in as RT's root user so we have full
+rights on the asset configuration. You could also create an "Asset Admin" group
+and assign appropriate rights to allow other users to manage catalogs.
+
+When you log in you'll see a new Assets menu, but before looking there we need
+to look at catalogs and some other configuration. Catalogs are to assets what
+queues are to tickets, so if you've used RT, the relationship should be fairly
+familiar. Similar to the General queue, a "General assets" catalog is provided
+to get you started. You can see it at Admin > Assets > Catalogs.
+
+We're going to use the default, but change it to a name more appropriate for
+our use. Clicking on the asset name brings us to the catalog edit page and we
+can update the name to "IT Department Assets". You can update the description
+if you like as well.
+
+=begin HTML
+
+<p><img src="http://static.bestpractical.com/images/assets/edit-catalog.png"
+alt="Edit Catalog" /></p>
+
+=end HTML
+
+You'll also notice that catalogs have a lifecycle just like queues. The assets
+extension comes with a default assets lifecycle, but just like queues you can
+create new ones with custom statuses and other configuration to allow RT to
+reflect the states of your assets.
+
+You can find the asset lifecycle in the asset configuration file in your RT
+installation at:
+
+ local/plugins/RT-Extension-Assets/etc/Assets_Config.pm
+
+The initial statuses are new, allocated, in-use, recycled, stolen, and deleted.
+Depending on your process, you might add new ones like surplussed, donated, or
+in-repair. To create a new asset lifecycle, just copy the default into
+F<RT_SiteConfig.pm>, replace the top-level "assets" key with a new name, and
+make your changes.
+
+=head1 Asset Custom Fields
+
+Next we need to create some custom fields to hold our asset metadata. You can
+find asset custom fields at Admin > Assets > Custom Fields and they work just
+like custom fields for other RT objects.
+
+=begin HTML
+
+<p><img src="http://static.bestpractical.com/images/assets/asset-cfs.png"
+alt="Asset Custom Fields" /></p>
+
+=end HTML
+
+The extension will automatically provide some core values for your assets. Each
+asset can have a Name and Description and, like tickets, they have statuses
+based on the lifecycle configuration. You can use Name and Description however
+you want and they are not required. However, many of the asset pages use these
+fields so it's best to provide a descriptive name to make it easy for people
+working in RT to identify the asset quickly. The manufacturer's product name
+can be convenient (e.g., '15" Macbook Pro').
+
+Assets come with three user fields you can associate with an asset: Owner, Held
+By, and Contact. These are provided to cover different types of assets, from
+laptops to servers to software, and different asset management situations.
+Owner can hold the user who bought the asset, maybe the head of the department
+where the budget came from. Held by is who the asset is assigned to. Laptops
+are assigned to a user and servers might be held (or managed) by the system
+administrators. Contact can be used to set a manager who might need to know
+about needed system updates or equipment with expiring support. Like tickets,
+these roles give you places to attach rights, so use them however they work
+best for you.
+
+Any other information you want to track will need custom fields. We'll start
+with a few basic fields:
+
+=over
+
+=item * Serial Number (enter one value)
+
+The serial number from the asset.
+
+=item * Tracking Number (enter one value)
+
+An internal tracking number. RT will assign an asset ID as well, but you may
+have other systems to integrate with or already have a way to assign asset ids
+for accounting purposes.
+
+=item * Manufacturer (dropdown)
+
+Company that made the asset.
+
+=item * Type (dropdown)
+
+Is it a laptop, server, or cell phone?
+
+=item * Issue Date (date)
+
+When the asset was given to the owner (or held by) person.
+
+Assets keep a transaction history like tickets, so you may be able pull this
+information from the "owner set to X" transaction. Creating a separate field
+makes it easier to report on.
+
+=item * Support Expiration (date)
+
+When the current support contract expires.
+
+=back
+
+=head1 Custom Field Grouping
+
+Any custom fields you create will be displayed on the asset display page in a
+default "Custom Fields" section. That may be sufficient, but assets also
+supports RT's new custom field grouping feature, so we can group together some
+similar custom fields and give them a custom name. If we add the following to
+F<RT_SiteConfig.pm>:
+
+ Set(%CustomFieldGroupings,
+ 'RT::Asset' => {
+ 'Asset Details' => ['Serial Number', 'Manufacturer', 'Type',
+ 'Tracking Number'],
+ 'Dates' => ['Support Expiration', 'Issue Date'],
+ },
+ );
+
+and restart RT, the dates will be tacked on the end of the Dates portlet and we
+get an Asset Details label on the other custom fields.
+
+=begin HTML
+
+<p><img
+src="http://static.bestpractical.com/images/assets/asset-date-details.png"
+alt="Asset Date and Details Display" /></p>
+
+=end HTML
+
+=head1 Asset Rights
+
+Now we've got the basic configuration in place to start recording asset data.
+Next we need to assign some rights so people can view and edit asset
+information. Our staff are all privileged users so we'll grant all view and
+modify rights on our catalog to the Privileged role. We'll also include rights
+to view and modify the catalog's custom fields, although you could set these
+rights individually on each custom field if you wanted to allow users to see
+some but not others.
+
+Similar to queues, you can set rights at the catalog level. Go to Admin >
+Assets > Catalogs and click on the catalog you want to edit. Click Group Rights
+in the submenu to assign asset rights to groups like the system Privileged
+group.
+
+=begin HTML
+
+<p><img src="http://static.bestpractical.com/images/assets/catalog-rights.png"
+alt="Catalog Rights" /></p>
+
+=end HTML
+
+We also want unprivileged users to be able to see their own assets to make it
+easier to submit support requests. To give them just the Name and Description
+on their own assets, we can grant SeeAssets and SeeCatalogs on the catalog to
+the Held By role.
+
+All of the asset rights are described in the Assets documentation. You can get
+much more detailed and fine-grained than this example, allowing selected groups
+and users to view and modify multiple different asset custom fields across many
+different catalogs.
+
+=head1 Working with Assets
+
+So now that we have all of that configuration done, what can we do? Here are a
+few scenarios to give you some ideas.
+
+=head2 Add Assets to Your Catalogs
+
+To start, staff can now start adding assets to RT allowing you to manage what
+you have, what state it's in, who currently has it, and when support expires.
+You could set up an intake process to get new assets added as they come in, and
+eventually have statuses updated as they are assigned, used, and eventually
+cycled out.
+
+If you already have an asset database, even something simple like a
+spreadsheet, you may be able to do an initial bulk import. Best Practical has
+released L<RT::Extension::Assets::Import::CSV> which is a CSV import tool to
+help you with this.
+
+=head2 Track Assets
+
+Your staff can now easily track work on assets by linking RT tickets to the
+assets. Assume you have an issue with an asset, like a server needs a new power
+supply. Your staff can use the asset search page to find the server. You'll
+notice that the RT search box is context sensitive, so when you're on an asset
+page, the search changes to Search Assets and you can search with that as well.
+
+Once you locate the server asset record, in the Actions menu you'll find
+"Create linked ticket", which does just that. You select the queue and which
+user to use from the asset as the Requestor, and you land on the ticket create
+page with some information pre-filled.
+
+=begin HTML
+
+<p><img
+src="http://static.bestpractical.com/images/assets/asset-ticket-create.png"
+alt="Create Ticket for Asset Work" /></p>
+
+=end HTML
+
+As you can see in the screenshot, when you create a ticket with a linked asset,
+you get an asset portlet on the create page and on the ticket display page as
+well. If you navigate back to the asset, you'll see a link back to the ticket
+in the Links section there. This gives you a record of all the tickets that
+have been opened against this asset. If this is a common scenario for you, you
+might even add a custom field on the ticket with the vendor tracking number of
+the repair. During the repair, you might flip the asset to an 'in-repair'
+status. Then when the ticket is resolved, flip it back to 'in-use'.
+
+=head2 End User Asset Tickets
+
+If an end user contacts us with some problems with their laptop, RT makes it
+easy to find the correct laptop record and create a ticket for them. Since our
+support staff do this frequently, they have added the Find User portlet to
+their RT at a glance page and can quickly search for the user and go to their
+User Summary page (new in RT 4.2).
+
+We have added the Assigned Assets portlet to the User Summary page, so the
+laptop is right there on the page when we find the user. We can just click on
+the asset, then use the "Create linked ticket" action as before to create the
+new repair ticket.
+
+=head2 End User Self Service
+
+Assume we already assign passwords to our unprivileged users so they can use
+RT's self service interface to submit tickets and they have basic permissions
+to do so (SeeQueue on the designated queue, CreateTicket, etc.). Since we've
+given some asset rights to unprivileged users, they can use RT's Self Service
+interface to find their assets (e.g., laptops, cell phones, etc.) when
+submitting support requests.
+
+When they log into the self service interface, they will see an Assets menu
+that takes them to a page displaying assets assigned to them. In our example
+configuration, this is based on the Held by setting we set when we gave out the
+laptop. When they navigate to the asset, they will see the Actions menu with
+the same "Create linked ticket" action our staff uses. When they click on that,
+they'll end up on the simplified ticket create page for self service. When the
+ticket is created, the laptop will already be linked to it, saving our staff
+the work.
+
+=begin HTML
+
+<p><img
+src="http://static.bestpractical.com/images/assets/asset-ticket-create.png"
+alt="Create Ticket for Asset Work" /></p>
+
+=end HTML
+
+=head1 Summary
+
+This tutorial is only a quick overview showing how the assets extension can
+help you track assets. There are many more features you'll find as you explore
+the assets interface, like stacking multiple assets on a single ticket, bulk
+update features similar to tickets, and the search interface. Have fun!
+
+1;
commit 6efb04bdad0c3454c486fa7b854428eb2a971745
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Dec 13 14:50:40 2013 -0500
Check in images
We'll host these on static.bestpractical.com, but check them
in to track them with the extension and make them available
locally for users.
diff --git a/doc/images/asset-cfs.png b/doc/images/asset-cfs.png
new file mode 100644
index 0000000..ebaf498
Binary files /dev/null and b/doc/images/asset-cfs.png differ
diff --git a/doc/images/asset-date-details.png b/doc/images/asset-date-details.png
new file mode 100644
index 0000000..4e8b21b
Binary files /dev/null and b/doc/images/asset-date-details.png differ
diff --git a/doc/images/asset-search.png b/doc/images/asset-search.png
new file mode 100644
index 0000000..debc158
Binary files /dev/null and b/doc/images/asset-search.png differ
diff --git a/doc/images/asset-ticket-create.png b/doc/images/asset-ticket-create.png
new file mode 100644
index 0000000..51f2fc5
Binary files /dev/null and b/doc/images/asset-ticket-create.png differ
diff --git a/doc/images/catalog-rights.png b/doc/images/catalog-rights.png
new file mode 100644
index 0000000..a4e9079
Binary files /dev/null and b/doc/images/catalog-rights.png differ
diff --git a/doc/images/edit-catalog.png b/doc/images/edit-catalog.png
new file mode 100644
index 0000000..9520930
Binary files /dev/null and b/doc/images/edit-catalog.png differ
diff --git a/doc/images/self-service-display.png b/doc/images/self-service-display.png
new file mode 100644
index 0000000..11dc3b5
Binary files /dev/null and b/doc/images/self-service-display.png differ
commit 12bec04b95fdce8866e2696209344124637a967f
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Dec 13 15:02:07 2013 -0500
Move getting started docs into primary module file
This will make it much easier to find on metacpan. We can
move it back to docs when it becomes part of RT.
diff --git a/doc/getting-started.pod b/doc/getting-started.pod
deleted file mode 100644
index f048aca..0000000
--- a/doc/getting-started.pod
+++ /dev/null
@@ -1,205 +0,0 @@
-=encoding utf8
-
-=head1 Assets in RT
-
-Assets start as a small set of fundamental record data upon which you build
-custom fields (CFs) of any type you like to describe the assets you want to
-track. By themselves, before you setup any CFs, assets are not very useful.
-
-Just like tickets are assigned to queues, assets are assigned to B<catalogs>.
-The default catalog is named "General assets", but we suggest you rename it and
-add additional catalogs to better fit your organization.
-
-You may want to use catalogs to separate assets into departments, general type
-of asset, hardware vs. software, etc. Catalogs, like queues, are generally
-easiest to work with when there's more than few but less than many dozen. The
-catalog of an asset should represent some fundamental quality of it (and many
-other assets!), that could just as easily be expressed as a custom field, but
-which is more important than other qualities for categorizing, sorting, and
-searching.
-
-=head2 Managing catalogs
-
-Catalogs are managed by RT adminstrators, or anyone with the L</AdminCatalog>
-right. You can find the list of catalogs, create new catalogs, and manage
-existing ones under the Tools → Configuration → Assets → Catalogs menu.
-
-Currently you need to log out and log back in to see changes to catalogs in any
-of the catalog selection dropdowns. This doesn't affect the catalog name
-displayed on individual asset pages.
-
-=head2 Adding fields
-
-You can see the current asset CFs by navigating to Tools → Configuration →
-Assets → Custom Fields. From there you can use the "Create" link to create a
-new asset CF. If you know you want to create a new CF right away, you can do
-so via Tools → Configuration → Assets → Custom Fields → Create.
-
-When creating a CF, be sure to select "Assets" in the "Applies To" dropdown.
-You'll also need to grant rights to the groups and/or roles which need to see
-the fields, otherwise they'll be hidden. See the following section.
-
-Similar to ticket CFs, asset custom fields are added globally or to specific
-catalogs. Only assets within those specific catalogs will have the CFs
-available. After creating a CF, you'll need to visit the "Applies To" page to
-add it to the catalogs you want or make it global.
-
-=head2 Rights
-
-There are three rights controlling basic access to assets and two for
-catalogs. Each right is grantable at the global level or individual catalog
-level, and grantable to system groups, asset roles, user groups, and individual
-users (just like ticket and queue rights).
-
-=head3 ShowAsset
-
-Allows viewing an asset record and it's core fields (but not CFs). Without
-it, no assets can be seen. Similar to ShowTicket.
-
-=head3 CreateAsset
-
-Allows creating assets and filling in the core fields (but not CFs). Without
-it, no assets can be created. Similar to CreateTicket.
-
-=head3 ModifyAsset
-
-Allows modifying existing assets and their core fields (but not CFs). Without
-it, basic asset data cannot be modified after creation. Similar to
-ModifyTicket.
-
-Most of your rights configuration will be on the CFs, and will likely need to
-be done for each CF. This lets you fine tune which fields are visible to
-individual groups and/or roles of users. Relevant CF rights are
-B<SeeCustomField> and B<ModifyCustomField>.
-
-Rights related to assets may also come from the L</Lifecycle statuses>
-configuration and restrict status transitions.
-
-=head3 ShowCatalog
-
-Allows seeing a catalog's name and other details when associated with assets.
-Without it, users will see "[a hidden catalog]" or a blank space where the
-catalog name would normally be. Similar to SeeQueue.
-
-=head3 AdminCatalog
-
-Allows creating new catalogs and modifying all aspects of existing catalogs,
-including changing the CFs associated with the catalog, granting/revoking
-rights, and adding/removing role members. This right should only be granted to
-administrators of RT. Similar to AdminQueue.
-
-=head3 Typical configuration
-
-A typical configuration grants the system Privileged group the following:
-B<ShowAsset>, B<CreateAsset>, B<ModifyAsset>, and B<ShowCatalog> globally, and
-B<SeeCustomField> and B<ModifyCustomField> globally on all asset CFs.
-
-If you want self service users (Unprivileged) to be able to view the assets
-they hold, grant the Held By role B<ShowAsset> and B<ShowCatalog> globally and
-B<SeeCustomField> on the necessary asset CFs.
-
-=head2 People and Roles
-
-Just like tickets, assets have various roles which users and groups may be
-assigned to. The intended usages of these roles are described below, but
-you're free to use them for whatever you'd like, of course.
-
-The roles provide ways to keep track of who is involved with each asset, as
-well as providing a place to grant rights that depend on the user's association
-with each asset.
-
-In addition to adding people to individual asset roles, you can also add role
-members at an entire catalog level. These catalog-level roles are useful in
-cases when you might have an entire catalog of assets for which the same people
-should be the Contacts, or which are Held By the same group. Unlike tickets
-where the queue watchers are invisible, catalog role members are visible
-because assets are generally much longer lived than tickets. When a problem
-with an asset arises, it's easier to see who to create a ticket for. On
-individual asset pages, catalog role members are shown with the text "(via this
-asset's catalog)" following each name.
-
-=head3 Owner
-
-The person responsible for the asset, perhaps the purchaser or manager.
-
-Restricted to a single user. Not available at a catalog level.
-
-=head3 Held By
-
-The person or people who physically possess the asset or are actively using the
-asset (if it isn't physical). This may be the same as the Contacts or may be
-different. For example, a computer workstation may be "held by" a university
-professor, but the contact may be the IT staff member responsible for all
-assets in the professor's department. This role is most similar to Requestor
-on tickets, although not equivalent.
-
-May be multiple users and/or groups.
-
-=head3 Contact
-
-The person or people who should be contacted with questions, problems,
-notifications, etc. about the asset. Contacts share some of the same intended
-usages of both Requestors and Ccs on tickets.
-
-May be multiple users and/or groups.
-
-=head2 Lifecycle statuses
-
-One of the basic asset fields is "Status". Similar to tickets, the valid
-statuses and their transitions and actions can be customized via RT's standard
-Lifecycles configuration (see "Lifecycles" in F<RT_Config.pm>). The default
-lifecycle is named "assets". You're free to modify it as much as you'd like,
-or add your own lifecycles. Each catalog may have its own lifecycle.
-
-For the default "assets" configuration, see F<etc/Assets_Config.pm>.
-
-=head2 Field organization
-
-=head3 Groupings
-
-You can organize your asset CFs into visual and logical "groupings" as you see
-fit. These groupings appear as separate boxes on the asset display page and
-become separate pages for editing (showing up in the per-asset menu).
-
-By default your CFs will appear in a B<Custom Fields> box on the asset display
-page and will be editable from a box of the same name on the B<Basics> editing
-page.
-
-Using the C<%CustomFieldGroupings> option (documented in F<etc/RT_Config.pm>),
-you can move individual CFs by name into one of the four built-in groupings
-(B<Basics>, B<People>, B<Dates>, and B<Links>) or create your own just by
-naming it. An example, assuming a date CF named "Purchased" and two "enter one
-value" CFs named "Weight" and "Color":
-
- # In etc/RT_SiteConfig.pm
- Set(%CustomFieldGroupings,
- 'RT::Asset' => {
- 'Dates' => ['Purchased'],
- 'Physical Properties' => ['Weight', 'Color'],
- },
- );
-
-This configuration snippet will move all three CFs out of the generic B<Custom
-Fields> box and into the B<Dates> box and a new box titled B<Physical
-Properties>. The "Purchased" CF will be editable from the Dates page and a new
-page titled "Physical Properties" will appear in the menu to allow editing of
-the "Weight" and "Color" CFs.
-
-=head3 Ordering
-
-Within a box, CFs come after any built-in asset fields such as Name,
-Description, Created, Last Updated, etc. The CFs themselves are ordered
-according to the sorting seen (and adjustable) on the global Asset Custom
-Fields page (Tools → Configuration → Global → Custom Fields → Assets) and the
-individual catalog Custom Fields pages (Tools → Configuration → Assets →
-Catalogs → (Pick one) → Custom Fields).
-
-Global asset CFs may be intermixed with per-catalog CFs with ordering.
-
-=head2 Importing existing data
-
-Another extension, L<RT::Extension::Assets::Import::CSV> provides tools to import
-new and update existing assets from a CSV dump. Its configuration lets you
-map the fields in the CSV to the asset fields you've already created in RT.
-
-=cut
diff --git a/lib/RT/Extension/Assets.pm b/lib/RT/Extension/Assets.pm
index 12c0f4a..3cd63d9 100644
--- a/lib/RT/Extension/Assets.pm
+++ b/lib/RT/Extension/Assets.pm
@@ -404,7 +404,6 @@ If you would like the MyAssets or FindAsset portlets to be available on
RT at a Glance and Dashboards, you will need to copy $HomepageComponents
from RT_Config.pm to RT_SiteConfig.pm and add them to the list.
-
If you would like the UserAssets portlet to show up on the User
Summary page, you will need to copy @UserSummaryPortlets from RT_Config.pm to
RT_SiteConfig.pm and add UserAssets to the list.
@@ -427,6 +426,208 @@ searching for assets; thereafter, it will defaultto the last-searched
catalog. You may use either the catalog's name or its ID. This only
affects the catalog selection on the asset search interface.
+=head1 USAGE
+
+Assets start as a small set of fundamental record data upon which you build
+custom fields (CFs) of any type you like to describe the assets you want to
+track. By themselves, before you setup any CFs, assets are not very useful.
+
+Just like tickets are assigned to queues, assets are assigned to B<catalogs>.
+The default catalog is named "General assets", but we suggest you rename it and
+add additional catalogs to better fit your organization.
+
+You may want to use catalogs to separate assets into departments, general type
+of asset, hardware vs. software, etc. Catalogs, like queues, are generally
+easiest to work with when there's more than few but less than many dozen. The
+catalog of an asset should represent some fundamental quality of it (and many
+other assets!), that could just as easily be expressed as a custom field, but
+which is more important than other qualities for categorizing, sorting, and
+searching.
+
+=head2 Managing catalogs
+
+Catalogs are managed by RT adminstrators, or anyone with the L</AdminCatalog>
+right. You can find the list of catalogs, create new catalogs, and manage
+existing ones under the Tools → Configuration → Assets → Catalogs menu.
+
+Currently you need to log out and log back in to see changes to catalogs in any
+of the catalog selection dropdowns. This doesn't affect the catalog name
+displayed on individual asset pages.
+
+=head2 Adding fields
+
+You can see the current asset CFs by navigating to Admin >
+Assets > Custom Fields. From there you can use the "Create" link to create a
+new asset CF. If you know you want to create a new CF right away, you can do
+so via Admin > Assets > Custom Fields > Create.
+
+When creating a CF, be sure to select "Assets" in the "Applies To" dropdown.
+You'll also need to grant rights to the groups and/or roles which need to see
+the fields, otherwise they'll be hidden. See the following section.
+
+Similar to ticket CFs, asset custom fields are added globally or to specific
+catalogs. Only assets within those specific catalogs will have the CFs
+available. After creating a CF, you'll need to visit the "Applies To" page to
+add it to the catalogs you want or make it global.
+
+=head2 Rights
+
+There are three rights controlling basic access to assets and two for
+catalogs. Each right is grantable at the global level or individual catalog
+level, and grantable to system groups, asset roles, user groups, and individual
+users (just like ticket and queue rights).
+
+=head3 ShowAsset
+
+Allows viewing an asset record and it's core fields (but not CFs). Without
+it, no assets can be seen. Similar to ShowTicket.
+
+=head3 CreateAsset
+
+Allows creating assets and filling in the core fields (but not CFs). Without
+it, no assets can be created. Similar to CreateTicket.
+
+=head3 ModifyAsset
+
+Allows modifying existing assets and their core fields (but not CFs). Without
+it, basic asset data cannot be modified after creation. Similar to
+ModifyTicket.
+
+Most of your rights configuration will be on the CFs, and will likely need to
+be done for each CF. This lets you fine tune which fields are visible to
+individual groups and/or roles of users. Relevant CF rights are
+B<SeeCustomField> and B<ModifyCustomField>.
+
+Rights related to assets may also come from the L</Lifecycle statuses>
+configuration and restrict status transitions.
+
+=head3 ShowCatalog
+
+Allows seeing a catalog's name and other details when associated with assets.
+Without it, users will see "[a hidden catalog]" or a blank space where the
+catalog name would normally be. Similar to SeeQueue.
+
+=head3 AdminCatalog
+
+Allows creating new catalogs and modifying all aspects of existing catalogs,
+including changing the CFs associated with the catalog, granting/revoking
+rights, and adding/removing role members. This right should only be granted to
+administrators of RT. Similar to AdminQueue.
+
+=head3 Typical configuration
+
+A typical configuration grants the system Privileged group the following:
+B<ShowAsset>, B<CreateAsset>, B<ModifyAsset>, and B<ShowCatalog> globally, and
+B<SeeCustomField> and B<ModifyCustomField> globally on all asset CFs.
+
+If you want self service users (Unprivileged) to be able to view the assets
+they hold, grant the Held By role B<ShowAsset> and B<ShowCatalog> globally and
+B<SeeCustomField> on the necessary asset CFs.
+
+=head2 People and Roles
+
+Just like tickets, assets have various roles which users and groups may be
+assigned to. The intended usages of these roles are described below, but
+you're free to use them for whatever you'd like, of course.
+
+The roles provide ways to keep track of who is involved with each asset, as
+well as providing a place to grant rights that depend on the user's association
+with each asset.
+
+In addition to adding people to individual asset roles, you can also add role
+members at an entire catalog level. These catalog-level roles are useful in
+cases when you might have an entire catalog of assets for which the same people
+should be the Contacts, or which are Held By the same group. Unlike tickets
+where the queue watchers are invisible, catalog role members are visible
+because assets are generally much longer lived than tickets. When a problem
+with an asset arises, it's easier to see who to create a ticket for. On
+individual asset pages, catalog role members are shown with the text "(via this
+asset's catalog)" following each name.
+
+=head3 Owner
+
+The person responsible for the asset, perhaps the purchaser or manager.
+
+Restricted to a single user. Not available at a catalog level.
+
+=head3 Held By
+
+The person or people who physically possess the asset or are actively using the
+asset (if it isn't physical). This may be the same as the Contacts or may be
+different. For example, a computer workstation may be "held by" a university
+professor, but the contact may be the IT staff member responsible for all
+assets in the professor's department. This role is most similar to Requestor
+on tickets, although not equivalent.
+
+May be multiple users and/or groups.
+
+=head3 Contact
+
+The person or people who should be contacted with questions, problems,
+notifications, etc. about the asset. Contacts share some of the same intended
+usages of both Requestors and Ccs on tickets.
+
+May be multiple users and/or groups.
+
+=head2 Lifecycle statuses
+
+One of the basic asset fields is "Status". Similar to tickets, the valid
+statuses and their transitions and actions can be customized via RT's standard
+Lifecycles configuration (see "Lifecycles" in F<RT_Config.pm>). The default
+lifecycle is named "assets". You're free to modify it as much as you'd like,
+or add your own lifecycles. Each catalog may have its own lifecycle.
+
+For the default "assets" configuration, see F<etc/Assets_Config.pm>.
+
+=head2 Field organization
+
+=head3 Groupings
+
+You can organize your asset CFs into visual and logical "groupings" as you see
+fit. These groupings appear as separate boxes on the asset display page and
+become separate pages for editing (showing up in the per-asset menu).
+
+By default your CFs will appear in a B<Custom Fields> box on the asset display
+page and will be editable from a box of the same name on the B<Basics> editing
+page.
+
+Using the C<%CustomFieldGroupings> option (documented in F<etc/RT_Config.pm>),
+you can move individual CFs by name into one of the four built-in groupings
+(B<Basics>, B<People>, B<Dates>, and B<Links>) or create your own just by
+naming it. An example, assuming a date CF named "Purchased" and two "enter one
+value" CFs named "Weight" and "Color":
+
+ # In etc/RT_SiteConfig.pm
+ Set(%CustomFieldGroupings,
+ 'RT::Asset' => {
+ 'Dates' => ['Purchased'],
+ 'Physical Properties' => ['Weight', 'Color'],
+ },
+ );
+
+This configuration snippet will move all three CFs out of the generic B<Custom
+Fields> box and into the B<Dates> box and a new box titled B<Physical
+Properties>. The "Purchased" CF will be editable from the Dates page and a new
+page titled "Physical Properties" will appear in the menu to allow editing of
+the "Weight" and "Color" CFs.
+
+=head3 Ordering
+
+Within a box, CFs come after any built-in asset fields such as Name,
+Description, Created, Last Updated, etc. The CFs themselves are ordered
+according to the sorting seen (and adjustable) on the global Asset Custom
+Fields page (Tools → Configuration → Global → Custom Fields → Assets) and the
+individual catalog Custom Fields pages (Tools → Configuration → Assets →
+Catalogs → (Pick one) → Custom Fields).
+
+Global asset CFs may be intermixed with per-catalog CFs with ordering.
+
+=head2 Importing existing data
+
+Another extension, L<RT::Extension::Assets::Import::CSV> provides tools to import
+new and update existing assets from a CSV dump. Its configuration lets you
+map the fields in the CSV to the asset fields you've already created in RT.
+
=head1 METHODS ADDED TO OTHER CLASSES
=head2 L<RT::CustomField>
@@ -467,7 +668,7 @@ matching the same criteria are found. Enabled CFs are preferentially loaded.
Takes a numeric L<RT::Catalog> ID. Limits the L<RT::CustomFields> collection
to only those fields applied directly to the specified catalog. This limit is
-OR'd with other L</LimitToCatalog> and L</LimitToGlobal> calls.
+OR'd with other L</LimitToCatalog> and C<LimitToGlobal> calls.
Note that this will cause the collection to only return asset CFs.
@@ -479,7 +680,7 @@ Thomas Sibley <trs at bestpractical.com>
All bugs should be reported via
L<http://rt.cpan.org/Public/Dist/Display.html?Name=RT-Extension-Assets>
-or L<bug-RT-Extension-Assets at rt.cpan.org>.
+or bug-RT-Extension-Assets at rt.cpan.org.
=head1 LICENSE AND COPYRIGHT
commit e45c0f9a433d69398cf34beb874c9081554d699a
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Dec 13 15:17:36 2013 -0500
Update README and MANIFEST
diff --git a/MANIFEST b/MANIFEST
index 795ebb5..e33775b 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -1,3 +1,87 @@
+doc/images/asset-cfs.png
+doc/images/asset-date-details.png
+doc/images/asset-search.png
+doc/images/asset-ticket-create.png
+doc/images/catalog-rights.png
+doc/images/edit-catalog.png
+doc/images/self-service-display.png
+etc/acl.mysql
+etc/acl.Oracle
+etc/acl.Pg
+etc/Assets_Config.pm
+etc/initialdata
+etc/schema.mysql
+etc/schema.Oracle
+etc/schema.Pg
+etc/schema.SQLite
+etc/Tutorial_Configuration.txt
+etc/tutorialdata
+html/Admin/Assets/Catalogs/Create.html
+html/Admin/Assets/Catalogs/CustomFields.html
+html/Admin/Assets/Catalogs/Elements/EditBasics
+html/Admin/Assets/Catalogs/GroupRights.html
+html/Admin/Assets/Catalogs/index.html
+html/Admin/Assets/Catalogs/Modify.html
+html/Admin/Assets/Catalogs/Roles.html
+html/Admin/Assets/Catalogs/UserRights.html
+html/Admin/Assets/index.html
+html/Admin/Global/CustomFields/Catalog-Assets.html
+html/Asset/Create.html
+html/Asset/CreateInCatalog.html
+html/Asset/CreateLinkedTicket.html
+html/Asset/Display.html
+html/Asset/Elements/AssetSearchBasics
+html/Asset/Elements/AssetSearchCFs
+html/Asset/Elements/AssetSearchPeople
+html/Asset/Elements/CreateInCatalog
+html/Asset/Elements/CreateLinkedTicket
+html/Asset/Elements/EditBasics
+html/Asset/Elements/EditDates
+html/Asset/Elements/EditPeople
+html/Asset/Elements/SelectCatalog
+html/Asset/Elements/SelectStatus
+html/Asset/Elements/ShowBasics
+html/Asset/Elements/ShowCatalog
+html/Asset/Elements/ShowDates
+html/Asset/Elements/ShowLinks
+html/Asset/Elements/ShowPeople
+html/Asset/Elements/ShowRoleMembers
+html/Asset/Elements/ShowSummary
+html/Asset/Helpers/CreateInCatalog
+html/Asset/Helpers/CreateLinkedTicket
+html/Asset/History.html
+html/Asset/index.html
+html/Asset/Modify.html
+html/Asset/ModifyCFs.html
+html/Asset/ModifyDates.html
+html/Asset/ModifyLinks.html
+html/Asset/ModifyPeople.html
+html/Asset/Search/Bulk.html
+html/Asset/Search/index.html
+html/Callbacks/RT-Extension-Assets/Elements/AddLinks/ExtraLinkInstructions
+html/Callbacks/RT-Extension-Assets/Elements/Tabs/Privileged
+html/Callbacks/RT-Extension-Assets/Elements/Tabs/SelfService
+html/Callbacks/RT-Extension-Assets/SelfService/Display.html/BeforeShowHistory
+html/Callbacks/RT-Extension-Assets/Ticket/Create.html/AfterBasics
+html/Callbacks/RT-Extension-Assets/Ticket/Elements/ShowSummary/LinksExtra
+html/Elements/Assets/AddPeople
+html/Elements/Assets/EditPeople
+html/Elements/Assets/EditRoleMembers
+html/Elements/Assets/Search
+html/Elements/Assets/SelectRoleType
+html/Elements/FindAsset
+html/Elements/MyAssets
+html/Elements/RT__Asset/ColumnMap
+html/Elements/RT__Catalog/ColumnMap
+html/SelfService/Asset/CreateLinkedTicket.html
+html/SelfService/Asset/Display.html
+html/SelfService/Asset/Helpers/CreateLinkedTicket
+html/SelfService/Asset/History.html
+html/SelfService/Asset/index.html
+html/Ticket/Elements/ShowAssets
+html/Ticket/Elements/ShowAssetsOnCreate
+html/User/Elements/AssetList
+html/User/Elements/Portlets/UserAssets
inc/Module/Install.pm
inc/Module/Install/Base.pm
inc/Module/Install/Can.pm
@@ -6,10 +90,32 @@ inc/Module/Install/Makefile.pm
inc/Module/Install/Metadata.pm
inc/Module/Install/ReadmeFromPod.pm
inc/Module/Install/RTx.pm
+inc/Module/Install/RTx/Factory.pm
+inc/Module/Install/Substitute.pm
inc/Module/Install/Win32.pm
inc/Module/Install/WriteAll.pm
+lib/RT/Asset.pm
+lib/RT/Assets.pm
+lib/RT/Catalog.pm
+lib/RT/Catalogs.pm
lib/RT/Extension/Assets.pm
+lib/RT/Extension/Assets/Tutorial.pm
+lib/RT/Lifecycle/Asset.pm
+lib/RT/URI/asset.pm
Makefile.PL
MANIFEST This list of files
+MANIFEST.SKIP
META.yml
+po/assets.pot
+po/en.po
README
+static/css/RTx-Assets.css
+static/js/RTx-Assets.js
+xt/api.t
+xt/collection.t
+xt/compile.t
+xt/lib/RT/Extension/Assets/Test.pm.in
+xt/links.t
+xt/rights.t
+xt/roles.t
+xt/web.t
diff --git a/README b/README
index cbbeb20..9826826 100644
--- a/README
+++ b/README
@@ -43,6 +43,198 @@ CONFIGURATION
catalog. You may use either the catalog's name or its ID. This only
affects the catalog selection on the asset search interface.
+USAGE
+ Assets start as a small set of fundamental record data upon which you
+ build custom fields (CFs) of any type you like to describe the assets
+ you want to track. By themselves, before you setup any CFs, assets are
+ not very useful.
+
+ Just like tickets are assigned to queues, assets are assigned to
+ catalogs. The default catalog is named "General assets", but we suggest
+ you rename it and add additional catalogs to better fit your
+ organization.
+
+ You may want to use catalogs to separate assets into departments,
+ general type of asset, hardware vs. software, etc. Catalogs, like
+ queues, are generally easiest to work with when there's more than few
+ but less than many dozen. The catalog of an asset should represent some
+ fundamental quality of it (and many other assets!), that could just as
+ easily be expressed as a custom field, but which is more important than
+ other qualities for categorizing, sorting, and searching.
+
+ Managing catalogs
+ Catalogs are managed by RT adminstrators, or anyone with the
+ "AdminCatalog" right. You can find the list of catalogs, create new
+ catalogs, and manage existing ones under the Tools → Configuration →
+ Assets → Catalogs menu.
+
+ Currently you need to log out and log back in to see changes to catalogs
+ in any of the catalog selection dropdowns. This doesn't affect the
+ catalog name displayed on individual asset pages.
+
+ Adding fields
+ You can see the current asset CFs by navigating to Admin > Assets >
+ Custom Fields. From there you can use the "Create" link to create a new
+ asset CF. If you know you want to create a new CF right away, you can do
+ so via Admin > Assets > Custom Fields > Create.
+
+ When creating a CF, be sure to select "Assets" in the "Applies To"
+ dropdown. You'll also need to grant rights to the groups and/or roles
+ which need to see the fields, otherwise they'll be hidden. See the
+ following section.
+
+ Similar to ticket CFs, asset custom fields are added globally or to
+ specific catalogs. Only assets within those specific catalogs will have
+ the CFs available. After creating a CF, you'll need to visit the
+ "Applies To" page to add it to the catalogs you want or make it global.
+
+ Rights
+ There are three rights controlling basic access to assets and two for
+ catalogs. Each right is grantable at the global level or individual
+ catalog level, and grantable to system groups, asset roles, user groups,
+ and individual users (just like ticket and queue rights).
+
+ ShowAsset
+ Allows viewing an asset record and it's core fields (but not CFs).
+ Without it, no assets can be seen. Similar to ShowTicket.
+
+ CreateAsset
+ Allows creating assets and filling in the core fields (but not CFs).
+ Without it, no assets can be created. Similar to CreateTicket.
+
+ ModifyAsset
+ Allows modifying existing assets and their core fields (but not CFs).
+ Without it, basic asset data cannot be modified after creation. Similar
+ to ModifyTicket.
+
+ Most of your rights configuration will be on the CFs, and will likely
+ need to be done for each CF. This lets you fine tune which fields are
+ visible to individual groups and/or roles of users. Relevant CF rights
+ are SeeCustomField and ModifyCustomField.
+
+ Rights related to assets may also come from the "Lifecycle statuses"
+ configuration and restrict status transitions.
+
+ ShowCatalog
+ Allows seeing a catalog's name and other details when associated with
+ assets. Without it, users will see "[a hidden catalog]" or a blank space
+ where the catalog name would normally be. Similar to SeeQueue.
+
+ AdminCatalog
+ Allows creating new catalogs and modifying all aspects of existing
+ catalogs, including changing the CFs associated with the catalog,
+ granting/revoking rights, and adding/removing role members. This right
+ should only be granted to administrators of RT. Similar to AdminQueue.
+
+ Typical configuration
+ A typical configuration grants the system Privileged group the
+ following: ShowAsset, CreateAsset, ModifyAsset, and ShowCatalog
+ globally, and SeeCustomField and ModifyCustomField globally on all asset
+ CFs.
+
+ If you want self service users (Unprivileged) to be able to view the
+ assets they hold, grant the Held By role ShowAsset and ShowCatalog
+ globally and SeeCustomField on the necessary asset CFs.
+
+ People and Roles
+ Just like tickets, assets have various roles which users and groups may
+ be assigned to. The intended usages of these roles are described below,
+ but you're free to use them for whatever you'd like, of course.
+
+ The roles provide ways to keep track of who is involved with each asset,
+ as well as providing a place to grant rights that depend on the user's
+ association with each asset.
+
+ In addition to adding people to individual asset roles, you can also add
+ role members at an entire catalog level. These catalog-level roles are
+ useful in cases when you might have an entire catalog of assets for
+ which the same people should be the Contacts, or which are Held By the
+ same group. Unlike tickets where the queue watchers are invisible,
+ catalog role members are visible because assets are generally much
+ longer lived than tickets. When a problem with an asset arises, it's
+ easier to see who to create a ticket for. On individual asset pages,
+ catalog role members are shown with the text "(via this asset's
+ catalog)" following each name.
+
+ Owner
+ The person responsible for the asset, perhaps the purchaser or manager.
+
+ Restricted to a single user. Not available at a catalog level.
+
+ Held By
+ The person or people who physically possess the asset or are actively
+ using the asset (if it isn't physical). This may be the same as the
+ Contacts or may be different. For example, a computer workstation may be
+ "held by" a university professor, but the contact may be the IT staff
+ member responsible for all assets in the professor's department. This
+ role is most similar to Requestor on tickets, although not equivalent.
+
+ May be multiple users and/or groups.
+
+ Contact
+ The person or people who should be contacted with questions, problems,
+ notifications, etc. about the asset. Contacts share some of the same
+ intended usages of both Requestors and Ccs on tickets.
+
+ May be multiple users and/or groups.
+
+ Lifecycle statuses
+ One of the basic asset fields is "Status". Similar to tickets, the valid
+ statuses and their transitions and actions can be customized via RT's
+ standard Lifecycles configuration (see "Lifecycles" in RT_Config.pm).
+ The default lifecycle is named "assets". You're free to modify it as
+ much as you'd like, or add your own lifecycles. Each catalog may have
+ its own lifecycle.
+
+ For the default "assets" configuration, see etc/Assets_Config.pm.
+
+ Field organization
+ Groupings
+ You can organize your asset CFs into visual and logical "groupings" as
+ you see fit. These groupings appear as separate boxes on the asset
+ display page and become separate pages for editing (showing up in the
+ per-asset menu).
+
+ By default your CFs will appear in a Custom Fields box on the asset
+ display page and will be editable from a box of the same name on the
+ Basics editing page.
+
+ Using the %CustomFieldGroupings option (documented in etc/RT_Config.pm),
+ you can move individual CFs by name into one of the four built-in
+ groupings (Basics, People, Dates, and Links) or create your own just by
+ naming it. An example, assuming a date CF named "Purchased" and two
+ "enter one value" CFs named "Weight" and "Color":
+
+ # In etc/RT_SiteConfig.pm
+ Set(%CustomFieldGroupings,
+ 'RT::Asset' => {
+ 'Dates' => ['Purchased'],
+ 'Physical Properties' => ['Weight', 'Color'],
+ },
+ );
+
+ This configuration snippet will move all three CFs out of the generic
+ Custom Fields box and into the Dates box and a new box titled Physical
+ Properties. The "Purchased" CF will be editable from the Dates page and
+ a new page titled "Physical Properties" will appear in the menu to allow
+ editing of the "Weight" and "Color" CFs.
+
+ Ordering
+ Within a box, CFs come after any built-in asset fields such as Name,
+ Description, Created, Last Updated, etc. The CFs themselves are ordered
+ according to the sorting seen (and adjustable) on the global Asset
+ Custom Fields page (Tools → Configuration → Global → Custom Fields →
+ Assets) and the individual catalog Custom Fields pages (Tools →
+ Configuration → Assets → Catalogs → (Pick one) → Custom Fields).
+
+ Global asset CFs may be intermixed with per-catalog CFs with ordering.
+
+ Importing existing data
+ Another extension, RT::Extension::Assets::Import::CSV provides tools to
+ import new and update existing assets from a CSV dump. Its configuration
+ lets you map the fields in the CSV to the asset fields you've already
+ created in RT.
+
METHODS ADDED TO OTHER CLASSES
RT::CustomField
LoadByNameAndCatalog
@@ -93,3 +285,10 @@ LICENSE AND COPYRIGHT
The GNU General Public License, Version 2, June 1991
+POD ERRORS
+ Hey! The above document had some coding errors, which are explained
+ below:
+
+ Around line 451:
+ Non-ASCII character seen before =encoding in '→'. Assuming UTF-8
+
-----------------------------------------------------------------------
More information about the Bps-public-commit
mailing list