I am using SAP Commerce 2011 and I have a WCMS site with 4 base stores, each having a different product catalog. I have also logic that lets the user select which base store he wants to see. Selecting a base store sets the related catalog version in session, using
DefaultCMSSiteService.setCurrentCatalogVersion.
This works well, but not in SmartEdit. The CMSSiteFilter calls the method getContextInformationLoader().initializePreviewRequest with every request. This gets the default product catalog of the WCMS site and set its active version in session, overriding my logic above. Therefore, I can not open the PDP in smartedit as a wrong catalog version is referenced.
I wonder why smartedit does not support such a standard scenario of having multiple base stores, eahc with different product catalog!
Any idea how to solve this?
It turns out, that smart edit code does not consider the case of having multiple base stores per site and a product catalog per base store. The workaround I implemented is the following:
Disable the ActiveBaseSitePreviewStrategy.
Explanation:
The method getContextInformationLoader().initializePreviewRequest calls 3 strategies to initialize the preview request. The above is one of them. It sets in the session the active site together with other things, among which is the default catalog version.
We want only to set the active site. This and also the other things set by this strategy, they are set in other places in the code. So this strategy is not necessary.
So in a custom extension xxx-spring.xml add the following
<alias name="defaultPreviewRequestStrategiesList" alias="previewRequestStrategiesList" />
<util:list id="defaultPreviewRequestStrategiesList">
<ref bean="catalogVersionsPreviewStrategy" />
<ref bean="uiExperienceLevelPreviewStrategy" />
</util:list>
defaultPreviewRequestStrategiesList represents the list of strategies injected in ContextInformationLoader (see acceleratorcms-spring). I just removed ActiveBaseSitePreviewStrategy from it.
Related
I have create a new custom view in Maximo DB, added it through the Database Configuration.
Created an application on top to display the data based on that view.
Added new signature option CREATEREPT to use default dialog to create reports (Ad Hoc Reports).
When I try to preview any report in that dialog, I get the following error
BMXAA8093E - The report could not be created and the cause of the
error cannot be determined. Try to create the report again, or contact
your system administrator.
null
It appears error BMXAA8093E can occur in a few different scenarios where a problem occurs with a report and a more specific explanation can't be provided:
https://www.ibm.com/support/pages/error-trying-save-qbr-or-create-new-report
I would suggest first confirming if a more specific error or any additional information is provided in the application logs. Following that you may want to verify that you have a Report Object Structure (ROS) for the object structure based on your custom view (i.e. in Integration -> Object Structures there is a record with "Consumed By" set to "Reporting" that has your object structure based on the custom view as a source object). Although you mentioned adding a Signature Option it is not clear from your description whether a ROS (mentioned earlier) exists and whether Administration -> Report Administration -> Set Report Object Structure Security has been used to tie that ROS to an existing security group or groups.
I had the same issue. Here is the solution that worked for me: go to Database Configuration, select your view, ensure that EXTENDSOBJECT is populated. In my case, it was not. You can fix this from backend. Let's assume your extended object is ASSET and your view is MYVIEW:
update maximo.maxobject set EXTENDSOBJECT='ASSET' where objectname = 'MYVIEW';
update maximo.maxobjectcfg set EXTENDSOBJECT='ASSET' where objectname = 'MYVIEW'; commit;
Do NOT forget to restart the app server.
I'm using the Azure portal to create a SignUp policy.
But can't find a way to make certain fields mandatory. Is this possible?
You can do this in the standard policy (i.e. without custom policies) by going in the Page UI Customization, and for each page, selecting whether you want attributes to be optional or required. This gives you the capability to make an attribute optional in one page (e.g. local account sign-up) but mandatory on another (e.g. social account sign-up).
See the image below.
I'm referring to Randy Minder answer,
the comments <!-- Required claims --> and <!-- Optional claims --> ,
they don't seem to work, if placed only (?) inside the Technical Profile. Also those are not mentioned in the linked documentation. So I was struggling, how to make a newly created extension_attribute not mandatory.
Then after "trial and error", i found this post: restrictions. Apparently, if you add a restriction pattern, the field becomes mandatory. That is implicit and not mentioned in the documentation. Also a default value doesn't change this behavior.
You can solve this problem by making certain claims required or optional, as shown below.
You can learn more about here
This response is inaccurate and misleading - the Required / Optional in the example given are comments (and hence do not affect functionality) which refer to which fields are required / optional when writing the registration data to the underlying directory.
I am trying to use umbraco with uCommerce.
I have implemented SecureTrading as Payment provider in uCommerce. Now I need a solution to use OrderNumber in place of OdrderGuid to be used to identify the PurchaseOrder.
Currently OrderGuid is being sento to SecureTrading & this is being displayed in SecureTrading Transactions section. And due to this identifying the order is really hard.
We have appropriate value in OrderNumber field of PurchaseOrder table & we want to Display that value in SecureTrading's Transaction section.
Any way to achieve this?
If I try to write my own payment provider code, it'll be very huge task, also we have set the SecureTrading environment accordingly to uCommerce default preference.
Immediate help is required.
For more Detail
I have developed a DLL for my own customization as menthioned in http://docs.ucommerce.net/ucommerce/v7.3/payment-providers/integrating-a-payment-gateway.html But, that also is not working. the custom Payment Provider added in code(DLL) is not visible in backoffice to change the Payment Provider. There are all old entries for providers.
Even nothing shows up in cms Admin section for uCommerce Settings.
Thanks
Hi you can create a derrived version of the PageBuilder which will send the parameters to SecureTrading.
There's a protected virtual method you can override called "GetParameters".
It returns a dictionary that holds everything that will be send to SecureTrading.
You can set the "orderreference" in the dictionary to OrderNumber. This originally holds the orderguid.
Don't forget to register your page builder in the IoC container.
http://docs.ucommerce.net/ucommerce/v7.5/extending-ucommerce/register-a-component.html
You need to override the component by reusing the ID that the page builder has, which is: "SecureTradingPageBuilder". When overriding the page builder you don't have to change anything in the back office.
This should fix your problem :)
I am new to Liferay. Now I need to create the flow chart which has the Liferay table work flow in following scenarios,
1) What are the list of table will reflect/update if we create the site admin?
2) What are the list of table will reflect/update if we create the site?
I tried by opening database tables and noticed that USER_, CONTACT_ will reflect, But I need list of all the related tables which will reflect when we create the site and siteadmin? I am using Liferay 6.2 version.
Thanks in advance.
When you want to know the internals of any system it is always best to check the relevant source-code. So in this case you can check the source-code for those classes which are used for CRUD operations on User and Site.
1) What are the list of table will reflect/update if we create the site admin?
Site-administrator is a Role, which can be applied to a User created in Liferay.
So if you want all the tables that are created from User-creation till User is assigned the Site-administrator role for a particular site, there here are some which I can recollect:
User_ (Obvious)
Contact_ (not so obvious :-) )
Group_ (Users are also created as a record in this table since Users have public and private pages)
Address (if you add an address)
Phone (if you add a Phone)
Users_Roles (Power user role is assigned by default)
UserGroupRole (user and site-role relationship, Site-administrator is a Site-role)
Users_Groups (user and site relationship)
For others you should refer the source-code for UserLocalServiceImpl, RoleLocalServiceImpl and GroupLocalServiceImpl, check the relevant methods prefixed add, update etc.
The corresponding service.xml for these module would reveal the database tables being used.
2) What are the list of table will reflect/update if we create the site?
Sites are nothing but Groups in Liferay. So its obvious Group_ table is playing a big role.
Other tables also depend upon what configuration you are doing while creating a Site.
Then there would be other tables like Layout when you start creating pages for a Site.
I would strongly encourage to go ahead and explore the source code for the classes and you would understand the flow - when and what tables are affected.
Here is some convention which might help you traverse the source-code, almost every *LocalServiceImpl is associated with a *Model like UserLocalServiceImpl with UserModel and almost every *Model has a corresponding database table with the same name.
Also the name of the functionality would in most cases hints at what service classes are being used to connect to database, like adding a User would hint at using UserLocalServiceImpl.
Hope I have understood your question and have been able to give some proper direction.
If you want to know this because you also want to write to these tables: Don't go there! You should purely use the API to change the data that Liferay stores. Otherwise you will run into disasters some time in the future - promised.
For just getting the SQL commands that Liferay actually uses, configure portal-ext.properties and change this default value:
hibernate.show_sql=false
Then go to "Server Administration/Log Levels" and add a new category "org.hibernate.SQL", configure it to the level DEBUG. Then the results show up in the logs. Note that this log configuration is transient and will be reverted on next server start. If you want the setting to be persistent, you'll need to go into Liferay's log4j configuration files.
Remember: You don't want to write to the tables ever. Promise!
there are many standard objects e.g. AccountcontactRole, LetterHead, Approval etc. which can be retrieved using Salesforce APIs. What is the way to see these objects in Salesforce environment in browser?
Very roughly speaking - easiest cheat is to simply put the Id in the URL. So if your Salesforce instance is https://na1.salesforce.com then adding /001.... (any valid Account Id) will take you to this account. Similarly /016... will take you to "this" Letterhead record.
Some data is easily accessible to users - for example AccountContactRole should be available as related list under Account. If it isn't - probably the administrator removed it from page layout because the company decided to use only the straightforward Account - Contact relationship.
Some data like Letterheads, EmailTemplates, Approval processes is visible in the setup area (not all users have the "View Setup and Configuration" permission in their Profiles!)
*Share records (like AccountShare) would be visible after you click the Sharing button on the page layout (if it's not visible - again, check with Admin).
If you're using API to fetch the data, you probably can also use "describe" calls to fetch info which objects are available, what fields are present in the tables... Sometimes the "Frontdoor URLs" property is set (although I confess I'm not sure how to get it, http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_Schema_DescribeSObjectResult_instance_methods.htm doesn't mention it).
Also - if you haven't noticed yet - all Accounts start with "001". Try to guess where "/001" and "/001/o" links would lead.