The ASA has always supported the legacy concept of a 'name' (an IP number to title mapping).
Name:
name 192.168.88.0 printer-network
The ASA has always supported the concept of an 'object-group', which is one or more ip subnets given a title. Note that an object-group contains full subnet definitions, where a name only contains an IP number (and not a subnet).
Object-group:
object-group network printer-network-objgrp network-object 192.168.66.0 255.255.255.0
ASDM address object:
ASDM uses information from the configuration to display names for ip subnets that it parses from the configuration. ASDM used this display method even before the ASA platform introduced the 'object' type in version 8.3, and continues to use them today, however without the 'name' configuration integration. See below for more on this.
ASA 8.3 added support for network-objects that have a title, and contain a subnet and optionally define how translation is to be performed on that subnet.
Object:
object network printer-network subnet 192.168.99.0 255.255.255.0
Object-groups and objects share the same namespace; You can't create an object-group called 'test' and then configure an object called 'test'. However, one CAN configure an object with the same title as a name entry in the firewall; this would cause ASDM in version 8.3 to have an overlap between the ASDM address objects and the objects; ASDM might have an address-object titled 'printer-network' that referred to a different IP subnet than the object titled 'printer-network'. This is because a name entry doesn't denote anything about the subnet of the network specified; a name is simply a one-to-one ip to name replacement in the configuration of the firewall, and doesn't contain any subnet information. In the example above, the same title "printer-network" refers to an IP number in the 'name' object, but also refers to a singleton network object with a different ip subnet; thus the ambiguity.
So, how should ASDM handle this situation, now that the platform has introduced network objects? To avoid confusion, ASDM for 8.3 simply ignores the 'name' entries in the ASA configuration, which removes any potential collision between ASDM address object titles and network object titles. Since the ASA now supports objects, which have a customized title, but also indicate the full IP subnet of the object, the preferred method going forward is for users to create an object with a title for their ip subnets, and refer to those objects in their ACLs.
ASA(config)# sh run access-list 898 access-list 898 extended permit ip any object printer-network ASA(config)# sh access-list 898 access-list 898; 1 elements; name hash: 0x321849ca access-list 898 line 1 extended permit ip any object printer-network 0x64062b7a access-list 898 line 1 extended permit ip any 192.168.99.0 255.255.255.0 (hitcnt=0) 0x64062b7a ASA(config)#
ASDM will then display the title of the object in the ACL definition.
An upgrade from pre 8.3 to 8.3 configuration will auto-create objects from the NAT entries in the configuration, but it will not create objects from the entries it sees only in the ACL configuration. If an ACE referred to a subnet that was also specified in a nat statement, then when the upgrade process creates an object as part of the NAT migration, it will proceed insert this new network object into the ACL as well. So, after migration, depending on the NAT configuration some ACL lines might have objects with titles specified in the ACE, and some might just have IP subnets. This has led to some confusion, because pre-8.3 one might be used to seeing ASDM address objects in certain configuration panes of ASDM, whereas now they might only see the IP subnets (or perhaps they only see some network object titles) since ASDM now ignores the 'name' commands in the configuration.
ASDM does have an easy way to create a network object from a ASDM address object. In the Address pane of ASDM (View->Addresses), find the ip address matching your name and right-click to edit the entry. When you give it a title, ASDM will create a new network object with those parameters; the name entry will not be deleted from the CLI configuration, since the name might be used elsewhere in the config by other features.