Read/Write Order access to users from same organization

I am sure you have seen a similar error when trying to give access to commands for different roles.

Do not just override the command and return null from getResources() method that would void any access controls on the order commands associated and could causes security issues, the correct way of fixing such issues, is to figure out the correct PolicyGroup and create custom policies with the corresponding roles. An example would be as below. In this case, you need to give users Buyer(buy-side) role to create\copy orders.
CMN1501E: User does not have the authority to perform action "com.ibm.commerce.order.commands.OrderCopyCmd" on resource "com.ibm.commerce.user.objects._Organization_Stub" for command "AjaxOrderCopy


<Policy Name="CustomUsersFromSameBuyerOrgExecuteOrderCreateCommandsOnOrganizationResource"
         OwnerID="RootOrganization"
         UserGroup="AllUsers"
         ActionGroupName="OrderCreateCommands"
         ResourceGroupName="OrderDataResourceGroup"
         RelationGroupName="Buyer (buy-side)->BuyerOrganizationalEntity"
         PolicyType="groupableStandard">
    </Policy>      
     <Policy Name="CustomUsersFromSameBuyerOrgExecuteOrderCreateReadCommandsOnOrganizationResource"
         OwnerID="RootOrganization"
         UserGroup="AllUsers"
         ActionGroupName="OrderReadCommands"
         ResourceGroupName="OrderDataResourceGroup"
         RelationGroupName="Buyer (buy-side)->BuyerOrganizationalEntity"
         PolicyType="groupableStandard">
    </Policy>      
<Policy Name="CustomUsersFromSameBuyerOrgExecuteOrderCreateWriteCommandsOnOrganizationResource"
         OwnerID="RootOrganization"
         UserGroup="AllUsers"
         ActionGroupName="OrderWriteCommands"
         ResourceGroupName="OrderDataResourceGroup"
         RelationGroupName="Buyer (buy-side)->BuyerOrganizationalEntity"
         PolicyType="groupableStandard">
    </Policy>

    <PolicyGroup Name="CommonShoppingPolicyGroup" OwnerID="RootOrganization">
      <!-- Define policies in this policy group -->
      <PolicyGroupPolicy   Name="CustomUsersFromSameBuyerOrgExecuteOrderCreateCommandsOnOrganizationResource" PolicyOwnerID="RootOrganization" />
      <PolicyGroupPolicy   Name="CustomUsersFromSameBuyerOrgExecuteOrderCreateReadCommandsOnOrganizationResource" PolicyOwnerID="RootOrganization" />
      <PolicyGroupPolicy   Name="CustomUsersFromSameBuyerOrgExecuteOrderCreateWriteCommandsOnOrganizationResource" PolicyOwnerID="RootOrganization" />
    </PolicyGroup>

Order history read access users from same organization.

Read only access to users belonging to same organization and Organization Participant role for order history related databeans, the XML policies below is from the reference link below but they have an issue where on the role Buyer (buy-side) role name so that's fixed.
Buyer(buy-side) roles needs to defined on the organization using Org admin console.
if there is an hierarchy of organizations and the bottom organization is the parent organization for the users. All roles have to be defined to Organizations from Top-Down.
Add the xml fragments below to resource_acpolicies.xml and run ACPLoad.
Add new policy to allow participants to display the order beans for others in the organization:
Relation group: This defines all roles in this case Buyer(buy-side) to BuyingOrganizationalEntity

     <RelationGroup Name="Buyer (buy-side)->BuyerOrganizationalEntity" OwnerID="RootOrganization">
        <RelationCondition><![CDATA[
        <profile>
        <openCondition name="RELATIONSHIP_CHAIN">
        <parameter name="ROLE" value="Buyer (buy-side)"/>
        <parameter name="RELATIONSHIP"
        value="BuyingOrganizationalEntity"/>
        </openCondition>
        </profile>
        ]]></RelationCondition>
    </RelationGroup>
   
 Create a new Policy and use the RelationGroupName created above to the ResourceGroup, OrderDatabeanResourceGroup and ActionGroup, DisplayDatabeanActionGroup

        <Policy Name="ParticipantsOfOrgDisplayOrderDatabeanResourceGroup"
            OwnerID="RootOrganization"
            UserGroup="AllUsers"
            ActionGroupName="DisplayDatabeanActionGroup"
            ResourceGroupName="OrderDatabeanResourceGroup"
            RelationGroupName="ParticipantOf->BuyerOrganizationalEntity"
            PolicyType="groupableStandard">
    </Policy>
    <Policy Name="BuyersOfOrgDisplayOrderDatabeanResourceGroup"
            OwnerID="RootOrganization"
            UserGroup="AllUsers"
            ActionGroupName="DisplayDatabeanActionGroup"
            ResourceGroupName="OrderDatabeanResourceGroup"
            RelationGroupName="Buyer (buy-side)->BuyerOrganizationalEntity"
            PolicyType="groupableStandard">
    </Policy>
     
  Subscribe organizations to the new Access Control policies:         
     <PolicyGroup Name="B2BPolicyGroup" OwnerID="RootOrganization">
        <PolicyGroupPolicy
        Name="ParticipantsOfOrgDisplayOrderDatabeanResourceGroup"
        PolicyOwnerID="RootOrganization" />
        <PolicyGroupPolicy Name=
        "BuyersOfOrgDisplayOrderDatabeanResourceGroup"
        PolicyOwnerID="RootOrganization" />
    </PolicyGroup>   

Once the ACPLoad is run, you can validate using a SQL query.
select * from acpolicy where policyname like 'BuyersOfOrgDisplayOrderDatabeanResourceGroup'
select * from acpolicy where policyname like 'ParticipantsOfOrgDisplayOrderDatabeanResourceGroup'

References:
http://www.ibm.com/developerworks/websphere/library/techarticles/0908_callaghan/0908_callaghan1.html
http://www.ibm.com/developerworks/websphere/library/techarticles/0805_callaghan/0805_callaghan.html

Generated columns UP_* for case insensitive search in V7

You might not find anything while searching about this info center. At least not when I did the search.

In V7 data migration generates some new generated fields and these fields are tablename.UP_*  columns. These fields are used by out of the box case insensitive searches. The grouping functions such as to_lower or to_upper are expensive operations for search when dealing with vast data and that is one of the performance enhancements in V7.

I am pretty sure, if you use out of the box data migration tool for migrating to V7. It should take care of  these generated fields. These fields should not be populated from code, there are triggers in database that would take care of populating these fields.

e.g.
  "UP_MFNAME" VARCHAR(64) GENERATED ALWAYS AS (UPPER(MFNAME)) ,
  "UP_MFPARTNUMBER" VARCHAR(64) GENERATED ALWAYS AS (UPPER(MFPARTNUMBER))
  "UP_PARTNUMBER" VARCHAR(64) GENERATED ALWAYS AS (UPPER(PARTNUMBER)) )

References:
https://www-304.ibm.com/support/docview.wss?uid=swg21498502
http://www.ibm.com/developerworks/data/library/techarticle/0203adamache/0203adamache.html
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.dbobj.doc%2Fdoc%2Fc0020109.html

Order state diagram !!

Orde state Diagram
This is probably one of the interesting info center article regarding the state diagram of order status. It shows pretty good transition between states. If you decide to use custom statuses as a best practice choose lower case letters.




Reference:
http://publib.boulder.ibm.com/infocenter/wchelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.commerce.developer.doc%2Frefs%2Frosordstattran.htm

http://publib.boulder.ibm.com/infocenter/wchelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.commerce.user.doc%2Fconcepts%2Fcossostat.htm