Difference between Simple and Advanced Search

In Webtop the DQL issued by Simple Search and the DQL issued by Advanced Search are different. For example in Simple Search, if I search for a document called "always on" and enter this as such, the simple search text box the following DQL is issued:

SELECT ALL r_object_type,r_modify_date,r_object_id,r_lock_owner,i_vstamp,owner_name,r_version_label,i_is_reference,score,a_content_type,object_name,r_is_virtual_doc,r_link_cnt,r_content_size FROM dm_document SEARCH TOPIC ' ("*always*","*on*")'


For the Advanced search, if I carry out the same search the following DQL is issued:

SELECT ALL r_object_type,r_lock_owner,r_object_id,owner_name,i_is_reference,a_content_type,object_name,r_is_virtual_doc,r_link_cnt,lower(object_name) AS lowerobjname,r_content_size,r_version_label,r_modify_date FROM dm_document WHERE FOLDER('/Your Folder',DESCEND) AND lower(object_name) = lower('always on') ORDER BY 10 ASC,3 ASC


The differences in the two searches is as designed. Simple search matches the words searched against indexed text and properties such as, Filename, Descriptive name, Category and Author. Spaces or commas can be used to separate text / keywords and Webtop will search for all separated chunks of text using Verity queries, such as AND or OR. For more information regarding Simple Search, please refer to the "Using a Simple Search" section of the Webtop 5.2x User Guide.

In our example, a client searching for "always on" would be considered to be searching for keywords "always" AND "on". This is a non-issue with Advanced Search as it is a less ambiguous search.


Another example:
If I have a document called "NEW Vacation Request Form.doc" in my home cabinet. I may carry out the following searches:
1) Search for "NEW Vacation Request Form.doc" --> returns the document (full object_name)
- SEARCH TOPIC ' ("*NEW Vacation Request Form.doc*")'

2) Search for "NEW Vacation Request Form" --> returns the document (partial object_name)
- SEARCH TOPIC ' ("*NEW Vacation Request Form*")'

3) Search for NEW Vacation Request Form --> did not return as we know
- SEARCH TOPIC ' ("*NEW*","*Vacation*","*Request*","*Form*")'

ACCRUE selects documents that include at least one of the search elements you specify. The more search elements that are present, the higher the score will be. e.g. (computer, laptop). As you can see, ACCRUE is used to search content not object_name.

The workaround suggested is to enclose double quotes around the words in simple search.

Remove select Object from DocApp/Type

“Remove select Object from DocApp/Type” removes object from the docapp not from docbase, if you want to remove objects from docbase the in DAB, checkout docapp

Select the object, Go to Menu item Edit  Delete object(s) from Docbase.

Or

TBO objects reside in the docbase in the location "/System/Modules/TBO" with the object type "dmc_module". You can uninstall the TBO’s by destroying your custom TBO objects from docbase.

select r_object_id, r_object_type from dm_sysobject where folder('/System/Modules/TBO');

User is getting UCF_E_SPECIFY_APPLICATION: A valid application does not exist

symptoms

User is getting UCF_E_SPECIFY_APPLICATION: A valid application does not exist. when try to view or edit specific file even application exist on the machine.
Cause
No Registry entries to edit and view with the specific extension.

Resolution
The Win32 Native Library used by UCF to identity and launch applications on the client relies on entries in the Windows Registry to discover file-type/application associations. The sequence for identifying which application to use for a given type is as follows:
• Look for entries in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts matching the type
• For each sub-key found, the program identifier and name are recorded (i.e. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.asp\OpenWithProgids\aspfile)
• For each of the sub-keys, the program identifier is search for in HKEY_CLASSES_ROOT (i.e. HKEY_CLASSES_ROOT\aspfile)
• If there is a shell sub-key, then the 'shell\open\command' and 'shell\edit\command' values are used for launching the application. If only one is available, then it will be used for viewing and editing.
For an example of a key that works, check HKEY_CLASSES_ROOT\Excel.Sheet.8\shell\Open\command.
So, immediate solution user can choose viewer/editor in WDK Client Application, or to provide sub-keys in the Windows registry HKEY_CLASSES_ROOT\aspfile entry to indicate the shell/open/command and shell/edit/command values.

How do Acls work on folders

This has nothing to do with folder security, which is a different topic altogether.

A permission set, or ACL, on a folder, controls whether that folder is displayed in the Desktop and Intranet clients. It has nothing to do with whether a user can make changes to the documents within the folder. This is determined by the ACLs assigned to each document. Folders are visible to all users with BROWSE permission. A user with NONE cannot see a folder from their client. A folder does not protect documents inside. Users with access to those documents can still search for, find, and change those documents

Groups Vs Roles

Introduction

Whether you're a developer new to the Web Development Kit (WDK) or you're a system administrator trying to be efficient in your Documentum user management, you may have wondered why there are both groups and roles. This article explores the differences between them, and provides some guidance on how to decide when to use a group or a role.

In the Beginning, there were Groups

Groups are a convenient way of aggregating individual users, thereby simplifying the process of managing permissions. Specifically, groups can be used in the following ways:

In conjunction with an Access Control List (ACL) to assign object-level permissions to all members of the group

As the owner of a document to allow all members of the group to have ownership

As the performer of a workflow task to allow that task to be delivered to all members of the group (or optionally the first to receive it)

The Content Server Fundamentals manual provides the following example of using groups to control permissions: you might set up a group called engr and assign version permission to the engr group in an ACL applied to all engineering documents. All members of the engr group then have version permission on engineering documents.

Groups contain the following properties:

Name: the name of the Docbase group

Class: the type of group (added in Content Server 5 - more on this later)

Email address: the address for the group. If no value is entered, the group email address defaults to the group name.

Owner: the name of the Docbase owner who owns this group (most groups are owned by the Docbase owner, but normal users can have their own groups as well, although this feature is rarely used)

Administrator: specifies a user or group, in addition to a superuser and the group owner, who can modify the group (this allows a manager to maintain group membership without having system administration privileges to the rest of the system)

Alias set: the default alias set for the group (used in certain cases to resolve an Alias Set's scope)

Group is Global: indicates that the group is displayed only in the governing Docbase of a federation

Description: a user-friendly description of the group

Is Private: defines whether the group is private or public. Public groups are visible to all users, while a private group is visible only to the owner of the group.

And to make your user management even more flexible, a group can belong to another group, facilitating a hierarchical user structure within which individual users and groups can be combined in the same group.

Along Came Roles

The release of Content Server 5 ushered in the era of roles. A role is a special type of group. Prior to roles, there was only one type of group, now called a standard group. This type of group is used to assign object-level permissions and participation in workflows as described above.

Version 5 added two new types of groups, a role group and a domain group:

Role group: this type of group is assigned a particular role within a client application domain. As with standard groups, a role group may contain a set of users, other groups, or both. A role group is created by setting the group_class attribute to role and the group_name attribute to the role name.

Domain group: this represents a particular client domain. A domain group contains a set of role groups, corresponding to the roles recognized by the client application. Note that if you create a role as a domain, it is listed in the Groups list page, not the Roles list page.

Since a role is a specialized group, roles contain the same nine properties as groups, with restrictions on two of the properties (name and class) as discussed above.

Summary of the Differences

We've been focusing on the fact that roles are just a special type of group. So let's summarize by highlighting the differences:

Groups are used for object permissions; roles are used for application or function permissions.

Again we turn to the Content Server Fundamentals manual for an example of using roles and domains to control function permissions. Suppose you write a client application called report_generator that recognizes three roles: readers (users who read reports), writers (users who write and generate reports), and administrators (users who administer the application). To support the roles, you create three role groups, one for each role. The group_class is set to role for these groups, and the group names are the names of the roles: readers, writers, and administrators. Then, create a domain group by creating a group whose group_class is domain and whose group name is the name of the domain. In this case, the domain name is report_generator. The three role groups are the members of the report_generator domain group.

When a user starts the report_generator application, the application is responsible for examining its associated domain group and determining the role group to which the user belongs. The application is also responsible for ensuring that the user performs only the actions allowed for members of that role group. Content Server does not enforce client application roles, since this responsibility is delegated to the application via the domain group.

Once the roles exist in your Docbase, they can be reused across applications. Just create a new domain group and add any of the existing role groups (readers, writers, and administrators in the example above) to the new domain group.

Roles in Web Publisher

Web Publisher is already configured with the roles that are defined in the Web Publisher doc app:

wcm_content_author_role

wcm_content_manager_role

wcm_web_developer_role

wcm_administrator_role

Web publisher uses these roles to determine which features are available to the user. For example, content authors are not allowed to see cabinets and folders, while content managers can. Content managers are not allowed to access administrative features, while administrators can. These out-of-the-box roles are ready to be used within any Web Publisher application, and they can be extended if needed. Plus, you can create new roles as needed.

Roles in WebTop

Webtop and WDK components can be configured to use any role that is defined in the associated Docbase. If no roles are configured in the Docbase, or if the Docbase is pre-5.1, Webtop defaults to using the client capability model in which four client capability levels can be set as client_capability attributes on the dm_user object in the Docbase:

consumer

contributor

coordinator

administrator

If you create role groups in the Docbase, you can create roles named consumer, contributor, coordinator, and administrator. Your custom roles can contain these roles (or vice-versa), so that Webtop and WDK components will not need to be reconfigured for your custom roles.

What can cause the error: "DM_DOCBROKER_E_CONNECT_FAILED"?

ID: esg5033
SOLUTION

You may get the following errors when trying to log into the Docbase even though the Docbase is up, but no client can connect to it. IAPI on the Server machine can also give the following errors:

[DM_DOCBROKER_E_NETWORK_ERROR]error: "An error occured performing a network operation: (Unknown error code 112 (_nl_error_ = 10061)). Network specific error: (Winsock error: connection refused; server probably not running)."

[DM_DOCBROKER_E_CONNECT_FAILED]error: "Unable to connect to DocBroker. Please check your dmcl.ini file for a correct host. Network address: (INET_ADDR: family: 2, port: 1489, host: 199.82.105.56 (199.82.105.56, c7526938))."

[DM_DOCBROKER_E_REQUEST_FAILED_E]error: "The Docbroker request failed."

The customer with the problem has the following environment:

1. Docpage server is on a Solaris box.

2. No DNS service used.

3. The server.ini file indicates that the server projects to machine named 'ods_dms'

4. Client connects from an NT machine and uses the server machine's IP address instead of the hostname in its dmcl.ini file:

[DOCBROKER_PRIMARY]

host = 199.82.105.56 (tried both specifying the IP address or hostname but both

failed with the same errors)

5. From the client machine, telnet and ping using the server machine's IP address 199.82.105.56 both succeed.

Upon running 'dmqdocbroker -i' on the server machine and obtaining the docbase map, the following was output :

Docbroker network address : INET_ADDR: 02 5d1 ac10490a ods_dms 127.0.0.1

where ods_dms is the host machine name.

Checking the /etc/hosts file, the customer only has 1 entry:

127.0.0.1 localhost

RESOLUTION:

1. Add a second entry to the /etc/hosts file for the actual IP address of the host machine since 127.0.0.1 is only the local loop back address. In this case the new entry looks like:

199.82.105.56 ods_dms loghost

The above entry should exist by default if the OS had been set up properly. But in this case, we suspect the OS had not been properly set up causing the second entry to be missing.

2. Kill the docbase server process with Unix kill -9. Shutting down using the standard dm_shutdown_ods_dms script fails because IAPI cannot connect to the docbase at all.

3. Run dm_stop_docbroker to shutdown the docbroker process

4. Run dm_launch_docbroker to bring up the docbroker

5. Run dmqdocbroker to verify that the docbroker picks up the correct entry from the /etc/hosts file. The correct output looks like:

Docbroker network address : INET_ADDR: 02 5d1 ac10490a ods_dms 199.82.105.56

6. Run dm_start_ods_dms to start up the docbase.

Now all client connections succeed, because the docbroker's docbase map contains the correct network address.

How do I correct the errors and warnings reported by this consistency checker?

ID: esg29545
Related Bugs:
SOLUTION

More specifically the question is what is the impact of the following errors that still exist and how do we clean them up?

Here are the steps to clean them up:

NOTE: PLEASE ENSURE THAT YOU HAVE A DATABASE BACKUP WHICH YOU CAN USE TO RECOVER THE SYSTEM IN THE UNLIKELY EVENT OF A CORRUPTION

You must log on to the database as docbase owner and run the SQL queries;

--- QUERY---: select a.r_object_id as p1, a.i_chronicle_id as p2 from dm_sysobject_s a where a.i_chronicle_id <> '0000000000000000' and not exists (select * from dm_sysobject_s b where b.r_object_id = a.i_chronicle_id)

WARNING CC-0023: Sysobject with r_object_id '09006e7880082141' references a non-existent i_chronicle_id '09006e788008211f'

WARNING CC-0023: Sysobject with r_object_id '09006e788008214b' references a non-existent i_chronicle_id '09006e788008211f'

Problem:

For some reason the root version doesn't exist anymore. Normally, WE CAN delete this object because it does not have a root document

Steps:

- Need to get the dump of the objects and check which version are those and check the all tree

- Need to change in SQL the i_chronicle_id to the lower version and make it the root


In SQL

SQL> update dm_sysobject_s set i_chronicle_id='< who ever is the lower version>' where i_chronicle_id='09006e788008211f';

SQL> commit;
OR

SQL>delete from dm_sysobject_r where r_object_id ='09006e7880082141'

SQL>delete from dm_sysobject_s where r_object_id ='09006e7880082141'

--- QUERY---: select a.r_object_id as p1, a.i_antecedent_id as p2 from dm_sysobject_s a where a.i_antecedent_id <> '0000000000000000' and not exists (select * from dm_sysobject_s b where b.r_object_id = a.i_antecedent_id)

WARNING CC-0024: Sysobject with r_object_id '09006e7880082141' references a non-existent i_antecedent_id '09006e788008211f'

Problem:

In this particular case the i_chronicle_id which is the i_antecedent_id is gone, OR WILL BE DELETED FROM THE STEP ABOVE.

Steps:

- Need to update i_antecedent_id to 16 zeros


SQL> update dm_sysobject_s set i_antecedent_id='0000000000000000' where i_antecedent_id='09006e788008211f';

SQL> commit;

--- QUERY---: select a.r_object_id as p1, a.r_workflow_id as p2 from dmi_workitem_s a where not exists (select b.r_object_id from dm_workflow_s b where b.r_object_id = a.r_workflow_id)

WARNING CC-0043: dmi_workitem object with r_object_id '4a006e7880000119' references non-existent dm_workflow object with id '4d006e788000010c'

WARNING CC-0043: dmi_workitem object with r_object_id '4a006e788000011e' references non-existent dm_workflow object with id '4d006e788000010e'


Problem:


The workitem is pointing to a non-existing workflow instance probable related to a bug.


Steps:


- Dump the dmi_workitem object and set to 16 zeros the r_workflow_id

- Get the r_queue_item_id value and set the item_id to 16 zeros and delete_flag to true as solution of Warning CC-0042

- dm_QueueMgt will cleanup the queue_item and destroy the dmi_workitem object


Workitem:

API> fetch,c,4a006e7880000119


API> set,c,4a006e7880000119,r_workflow_id

SET> 0000000000000000


API> save,c,4a006e7880000119


Queue_item


API> fetch,c,1b006e788001d911


API> set,c,1b006e788001d911,item_id

SET> 0000000000000000


API> set,c,1b006e788001d911,delete_flag

SET> 1


API> save,c,1b006e788001d911


Workitem:


API> fetch,c,4a006e7880000119


API> destroy,c,4a006e7880000119



--- QUERY---: select a.r_object_id as p1, a.r_workflow_id as p2 from dmi_package_s a where not exists (select b.r_object_id from dm_workflow_s b where b.r_object_id = a.r_workflow_id)

WARNING CC-0045: dmi_package object with r_object_id '49006e7880000116' references non-existent dm_workflow object with id '4d006e788000010c'

WARNING CC-0045: dmi_package object with r_object_id '49006e7880000118' references non-existent dm_workflow object with id '4d006e788000010e'


Problem:


dmi_package is pointing to a non-existing workflow


Steps:


- Set the r_workflow_id to 16 zeros

- Destroy the dmi_package object


API> fetch,c,49006e7880000116


API> set,c,49006e7880000116,r_workflow_id

SET> 0000000000000000


API> save,c,49006e7880000116


API> fetch,c,49006e7880000116


API> destroy,c,49006e7880000116



--- QUERY---: select ws.r_object_id as p1, pr.r_component_id as p2 from dm_workflow_s ws, dm_workflow_r wr, dmi_package_s ps, dmi_package_r pr where ws.r_object_id = wr.r_object_id AND wr.r_act_state != 2 AND pr.r_component_id > '0000000000000000' AND ws.r_runtime_state IN (1,3) AND ws.r_object_id = ps.r_workflow_id AND wr.r_act_seqno = ps.r_act_seqno AND ps.r_object_id = pr.r_object_id AND not exists (select a.r_object_id from dm_sysobject_s a where a.r_object_id = pr.r_component_id)

WARNING CC-0046: dm_workflow object with r_object_id '4d006e7880002501' references non-existent sysobject with r_component_id '09006e788000dffd'

WARNING CC-0046: dm_workflow object with r_object_id '4d006e7880000d09' references non-existent sysobject with r_component_id '09006e7880006e60'


Problem:


The r_component_id of the dmi_package and is making reference to a workflow instance doesn't exist anymore


Steps:


- Set the r_component_id and r_component_chron_id (Chronicle ID of the object identified at the corresponding index position in r_component_id.) to 16 zeros and destroy it.

- Or set r_component_id to a existing package with his chronicle_id in r_component_chron_id


API> retrieve,c,dmi_package where r_workflow_id='4d006e7880002501'

...

4d0a636280000900

API> set,c,490a636280000900,r_component_id

Set >0000000000000000

...

Ok

API> set,c,490a636280000900,r_component_chron_id

Set >0000000000000000

...

Ok

API> save,c,490a636280000900

...

Ok



OR



API> set,c,490a636280000900,r_component_id

Set >090a636280004c85

...

Ok

API> set,c,490a636280000900,r_component_chron_id

Set >090a636280004655

...

Ok

API> save,c,490a636280000900

...

Ok



Check ACLs with non-existent users

WARNING CC-0007: ACL object with r_object_id '45006e5880000507' has a non-existent user 'test1'

WARNING CC-0007: ACL object with r_object_id '45006e5880000d00' has a non-existent user 'test1'


Problem:


The ACL contains a non-existing user in r_accessor_name attribute


Steps:


- Dump the acl

- Check the index for the non-existing user

- Using remove API call, remove the user per index and also make sure that you remove the same index for r_accessor_permit, r_accessor_xpermit and r_is_group attributes. If CS is 4.2.x this will not have r_accessor_xpermit


In API:


API> fetch,c,450a636280002512

...

Ok

API> dump,c,450a636280002512

...

USER ATTRIBUTES


object_name : peoplesoft_acl

description : peoplesoft permission set

owner_name : Miguel_Test52

globally_managed : F

acl_class : 0


SYSTEM ATTRIBUTES


r_object_id : 450a636280002512

r_is_internal : F

r_accessor_name [0]: dm_world

[1]: dm_owner

[2]: dmadmin

[3]: test1

r_accessor_permit [0]: 3

[1]: 7

[2]: 7

[3]: 7

r_accessor_xpermit [0]: 0

[1]: 0

[2]: 3

[3]: 3

r_is_group [0]: F

[1]: F

[2]: F

[3]: F

r_has_events : F


APPLICATION ATTRIBUTES



INTERNAL ATTRIBUTES


i_is_replica : F

i_vstamp : 1


In this case the index 3 contains the user that we need to remove (test1)


API> remove,c,450a636280002512,r_accessor_name[3]

...

Ok

API> remove,c,450a636280002512,r_accessor_permit[3]

...

Ok

API> remove,c,450a636280002512,r_accessor_xpermit[3]

...

Ok

API> remove,c,450a636280002512,r_is_group[3]

...

Ok

API> save,c,450a636280002512

...

Ok

API> dump,c,450a636280002512

...

USER ATTRIBUTES


object_name : peoplesoft_acl

description : peoplesoft permission set

owner_name : Miguel_Test52

globally_managed : F

acl_class : 0


SYSTEM ATTRIBUTES


r_object_id : 450a636280002512

r_is_internal : F

r_accessor_name [0]: dm_world

[1]: dm_owner

[2]: dmadmin

r_accessor_permit [0]: 3

[1]: 7

[2]: 7

r_accessor_xpermit [0]: 0

[1]: 0

[2]: 3

r_is_group [0]: F

[1]: F

[2]: F

r_has_events : F


APPLICATION ATTRIBUTES



INTERNAL ATTRIBUTES


i_is_replica : F

i_vstamp : 2


API



WARNING CC-0059: The dm_sysobject with id '0900f6ae80002980' references a non-existent policy object with id '46004a1a80003dae'


Need to update the r_policy_id for this object to 0000000000000000


SQL> insert into dm_policy_s values('46004a1a80003dae',2,NULL,'0000000000000000',NULL);


SQL> commit;



--- Query --- select a.name,a.s_index_attr from dm_type_s a where not exists(select b.r_object_id from dmi_index_s b where b.r_object_id=a.s_index_attr)


WARNING CC-0074: Type object for type 'dm_folder' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'

WARNING CC-0074: Type object for type 'dm_document' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'

WARNING CC-0074: Type object for type 'dm_note' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'

WARNING CC-0074: Type object for type 'dmi_dist_comp_record' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'

WARNING CC-0074: Type object for type 'dm_query' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'

WARNING CC-0074: Type object for type 'dm_script' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'

WARNING CC-0074: Type object for type 'dm_smart_list' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'

WARNING CC-0074: Type object for type 'dm_procedure' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'


Problem:


The type is pointing to a non-existing index in dmi_index



This is a harmless warning you can ignore. BUG# 65798 is logged on this issue and fixed in Content Server 5.3 OR if you really don't want to see this Warning, you can fix it like this;


EXAMPLE;


WARNING CC-0074: Type object for type 'dm_folder' references a non-existent dmi_index object for _s table with r_object_id '0000000000000000'


Steps:


- Confirm the value of the index by doing the following in SQLplus:


SQL> select S_INDEX_ATTR from dm_type_s where name='dm_folder';


S_INDEX_ATTR

----------------

1f001a9880000142


- Check the indexes for this type:


SQL> col index_name format a20

SQL> col column_name format a20

SQL> col column_position format 99999999990

SQL> select index_name,column_name,column_position from user_ind_columns where table_name like 'DM_FOLDER%';


INDEX_NAME COLUMN_NAME COLUMN_POSITION

-------------------- -------------------- ---------------

D_1F001A9880000143 R_OBJECT_ID 1

D_1F001A9880000143 I_POSITION 2

D_1F001A9880000015 R_FOLDER_PATH 1

D_1F001A9880000016 I_ANCESTOR_ID 1

D_1F001A9880000016 R_OBJECT_ID 2

D_1F001A9880000142 R_OBJECT_ID 1


6 rows selected.


SQL>


As you can see the the index name + D_ match with the value of S_INDEX_ATTR last row in the example.


You need to check if this index exists in dmi_index_s and _r


SQL> select count(*) from dmi_index_s where r_object_id='1f001a9880000142';


COUNT(*)

----------

1


SQL> select count(*) from dmi_index_r where r_object_id='1f001a9880000142';


COUNT(*)

----------

1


SQL>


You should not have the object in any of this tables if exists in one of this tables you must delete it.


SQL>delete from dmi_index_s where r_object_id='1f001a9880000142';


SQL>delete from dmi_index_r where r_object_id='1f001a9880000142';


OR


- Set the S_INDEX_ATTR to 16 zeros and then recreate the index using API with unique attribute "R_OBJECT_ID" as is state it above. update S_INDEX_ATTR from dm_type_s to the correct value without the D_ and that will fix the inconsistency