Portal enhancement requests.

[chris001]

The AOP joomla component probably needs to be radically enhanced for the next release.

1. First, a user connecting to the portal, should not trigger the creation of another username and password (neither in suitecrm nor in joomla or wordpress if/when wordpress will be supported).
   • Single Sign On is the way to go with this AOP portal.
   • Either joomla/wordpress or suitecrm should be the treated by AOP as the master user login authentication provider ie checks the login attempted email and password for go/no go.
   • Probably joomla/wordpress should be the one holding/managing/configured directly to communicate with the user authentication database (microsoft AD, openLDAP, and/or social network login providers) , since they're the front end web app where the contacts/leads interact with the organization/company.
   • A secure login to either the joomla SuiteCRM AOP portal joomla component, or wordpress SuiteCRM AOP portal wordpress plugin, as the frontend, should be securely trusted by suitecrm which is acting as the backend.
   • The first time the joomla/wordpress user tries to view their info in AOP portal, if suitecrm fails to find that email address in suitecrm, it should silently create a contact and populate it with the email address, name,IP, etc, and create a suite portal user, whose unique ID key is that email address, create a portal user login session for that email address, and from that time onward, let that portal user email have access to data in suitecrm related to that email address.
2. Portal user should be able to view and search MOST or ALL of the data, held in SuiteCRM, which is related to their portal user email address, and potentially, related to their Account (company/organization) although this may need to be restricted with SuiteCRM Security Groups based on the portal user's company role, for example a portal user who is a regular non-financial employee/member of an Account organization/company, might be restricted from viewing his Account's financial information, bank account numbers, transactions, etc.
   • Knowledge base (both global articles/posts and articles/posts they as a Contact, or their related Account, are related to).
   • Quotes,
   • Invoices,
   • Their own Contact info,
   • Contact info card plus web commenting similar to odoo and facebook comments, to communicate with their assigned reps in the organization, attach documents, etc.
   • Documents,
   • Not just Case/trouble ticket/support.
   • Would be nice to hide some related info, such as, the organization might want to prevent users from viewing internal Notes written about them and related to them, Calls history, Emails, etc.
   • view/search/pay online their Invoices thru the top payment providers such as paypal, authorize.net, worldpay, etc. Full list, http://www.businessnewsdaily.com/8061-best-credit-card-processing.html GPL licensed PHP code for most payment providers already exists.
   • view/search their reports on balance currently owing,
   • view/search their monthly statement reports,
   • view/search their payment history reports,
   • view/search Contracts they have signed including past Contracts,
   • view and search Products, pricing, and Product categories,
   • etc.

[pnob32]

Hi Chris,

I know I'm a bit late, but I have been working on a custom AOP portal for my company, and figured I could give you some advice in case you still wanted to use Joomla/AOP. If you are relatively experienced with PHP and/or Joomla development, or have someone who is, it is quite possible to create your own version of AOP to suit your own instance of SuiteCRM. I have been using the existing AOP code as more of a reference for using the SuiteCRM Rest API.

Basically, AOP is an example of using the API to create, update, and view cases based on the Case-Contact relationships you have set up in SuiteCRM. The code can be translated to any other [SuiteCRM] module, be it native or custom.

If your interested in doing some coding, best place to start looking is the Connector class files in the model directory, so you can write your own connectors for the [SuiteCRM] modules you need access to. Then you can create new views or edit the existing ones to display the data.

Sorry if this is irrelevant for you now, but I understand your frustration seeing that there is so much data in SuiteCRM that is not being handled by AOP. Hopefully this was useful for someone.

[horus68]

@pnob32 hope you can submit some code enhancements here, specially those modules connectors (or maybe just one to act as an example)

[chris001]

The best way IMHO is to generalize the portal so that it can run with very few changes on any content management system (CMS), whether joomla, wordpress, drupal, or other.

You separate out the view, which is depending on the CMS's API to display the interface and portal data on the HTML page, from the model, which depends on the CMS's database access layer, and the controller, which should be the same code on every CMS.

Currently the portal is joomla specific, yet could be adapted rather easily to detect and work on both joomla and wordpress, see above.

Also, the portal's only showing the customer's Cases. Customer is the Contact who is logged in.

The portal should be expanded to auto detect and show most if not every module.

Quotes and Invoices customers would like to have access to.

Let customers see all their history of Quotes and Invoices, and pay their unpaid invoices.

Let customers place Sales Orders, to a certain extent, out of the catalog, or Request For Quote, for custom items or items not in the catalog.

Let customers view and update their Contact and company's/organziation's Account records.

Upload user profile pictures, Documents, update social media contact info for people and the organization Account.

Add/update/remove email addresses, add/update/remove people from their organization.

Designate Accounting personnel allowed to view financial data and receive invoices, and pay.

Schedule calls, view call history, etc.

See also salesagility/SuiteCRM#2999