Change the maximum number of records to be displayed in a specific subpanel in SugarCRM 7 - limit

In SugarCRM 7.9 how we can change the maximum number of records to be displayed in a specific subpanel.
In Developer guide i have found that by changing the 'list_max_entries_per_subpanel' limit in config override we can change the records display limit for all subpanels but i want to have the effect only in my specific subpanel for example Contacts subpanel available in Accounts module.

I was interested to find out the answer to this too, so I did some digging and figured this out. As per your example of displaying a different number in the Contacts subpanel in Accounts, here's what you can do:
Add the following file to custom/modules/Contacts/clients/base/views/subpanel-list/subpanel-list.js
({
extendsFrom: "SubpanelListView",
initialize: function(options){
this._super("initialize", [options]);
if (this.context.get("parentModule") == "Accounts"){
this.context.set("limit",1);
}
}
})
If you'd like to know more specifically what's going on, I'll elaborate. Here's a breakdown of what's happening:
State that you're extending the standard subpanel list view.
Override the parent class' initialize function.
Call the parent initialize function (to ensure all superclass behaviour is respected)
If this (Contacts) subpanel has a parent module of Accounts (i.e. this subpanel is one of the ones displayed below the Accounts record view), then set the context property "limit" to the desired value.
I've tested this successfully by linking 3 contacts to an Account, and it only displayed 1, and subsequently linked 3 contacts to an Opportunity, and it showed all 3.

Related

Dynamics CRM limit "regarding" lookup field for only 1 entity on Appointment form and set default view for "Look in"

I am trying to limit entities that the user can select from on "Regarding" field on Appointment form and set some default views used by these lookup fields.
The big idea is that when user is entering data in the field itself, the results should be provided from default view for this lookup, e.g. "Contacts I follow", but when user enters "Lookup more records" pop-up the default view should be swapped to "All contacts".
This field can look up in many entities, e.g. Account, Contact, Billing, etc., and I want to limit it strictly to Accounts only.
So far I've found two ways of doing it:
1) Add filters to lookup fields, so that any records not fulfilling given criteria will not be shown. This is done using addPreSearch JS function from Xrm lib, like this:
var addEventHandler = function (defaultView) {
Xrm.Page.getControl("contactid").addPreSearch(function () {
addFilter("contactid", defaultView)
});
}
var addFilter = function (entityName, defaultView) {
var filterXml = "<filter type = 'and'>" +
"<condition attribute='contactid' operator='null'/>" +
"</filter>";
Xrm.Page.getControl("contactid").addCustomFilter(filterXml, "contact");
Xrm.Page.getControl("contactid").setDefaultView(defaultView);
}
(This is just sample code, not actually applied to the Regarding field)
2) Second option is to use undocumented solution by using setLookupTypes function on the field itself, like this:
var limitLookupEntities = function () {
Xrm.Page.getAttribute("contactid").setLookupTypes(["contact"]);
}
var changeDefaultViewForLookup = function(viewGuid){
Xrm.Page.getControl("contactid").setDefaultView(viewGuid);
}
The issue:
The problem is that as mentioned earlier, "Regarding" field can look up in many entities. Limiting them using the solution 1) is tedious, having to create as many filters as there are entities and applying them one by one to the field doesn't seem the right way to go. However, the way I implement this, the default view behaviour works as intended - the look-in value is only changed for the pop-up window.
Solution 2) is way easier to implement, and won't require any changes in the future if any new entities would be added to relationship with "Regarding" field, but the default view is applied to both "in-field" and "pop-up" default view.
The solution I'm looking for needs to do the following:
It should limit the search to specified entity only
It shouldn't require any maintaining after being implemented, e.g.
in case new entities are introduced to "Regarding" field.
It should be generic - I might want to be able to parametrize it and use it on other forms
It should apply the default view change only when user opens the pop-up search window
Is it even possible?
The CRM version I'm implementing this on is 8.2 on-prem.

Is it possible to create a user group in Joomla 2.5 that includes everyone that is NOT a member of a particular group?

I have two similar pages that need a menu link. Page 1 is shown to members of Group A. Page 2 is shown to everyone who is not a member of Group A. I have a "Guest" group which would include everyone who is not logged in. But some users are members of group A and Group B. I cannot figure out how to only show one link to them, based on whether they are a member of Group A or not. If I create an access level that includes only Group A and one that includes every other group and someone is in both groups, they will see both links, which is redundant since the pages are different versions of the same page. Any ideas?
We've got a similiar situation, and they way we got around it is to have another Usergroup called "GroupNotA". Then, we have a user plugin that we configure the UserGroups that are in play, and use the OnUserAfterSave event to insure everyone is conditionally in the correct user groups as shown in the code snippets below. With that, we can user menu items, etc. that are available to GroupA and GroupNotA.
myUserPlugin.xml
<field name="usergroup_a" type="usergroup" label="Group A" multiple="false" />
<field name="usergroup_not_a" type="usergroup" label="Group Not A" multiple="false" />
myUserPlugin.php
public function onUserBeforeSave($oldUser, $isnew, $newUser)
{
$UserGroupA = $this->params->get('usergroup_a');
$UserGroupNotA = $this->params->get('usergroup_not_a');
if(in_array(UserGroupA, $newUser['groups'])){
// Use IS in Group A - do nothing?
}else{
// Use is NOT in Group A - Add to group $UserGroupNotA
// add/remove from array $user['groups']
}
A word of caution though, the natural inclination was to use JUserHelper::addUserToGroup(), but it triggers OnUserAfterSave() again, so we went with direct manipulation of the Groups array.
A sample user plugin is installed with Joomla at plugins/user/example.php, and full documentation is available at Plugin/Events/User. Good Luck.
Note I just realized that we do this during a new user registration, so I'm altering the answer to use the event onUserBeforeSave(). I'm not sure that it will work as I originally suggested or not, but at least you have a starting point and the pieces to accomplish a solution.

Joomla progressive cache doesn't handle modules with variable output

I have a module which allows the user to choose a category, which is then used for filtering the component's output. So when the user first clicks on the menu item, the view shows items from all categories, then as they click on the module, a param such as &catid=69 etc. is added to the url and used to filter the items displayed.
A system plugin complements the behaviour by registering the extra catid param i.e.
$registeredurlparams->catid = 'INT';
$app->set('registeredurlparams', $registeredurlparams);
The module uses the category id to create the cache id, and shows the top-level categories + the subcategories of the category that was chosen.
This works fine with both conservative cache enabled in the system configuration and the System Cache plugin enabled.
My concern is that I cannot get it to work with progressive cache: even though the component output is cached correctly, the module doesn't get updated (so I never see the subcategories).
Eventually I plan to make the extension available on the JED, and I'd like to be compatible with all possible cache configurations. Is there any possibility to force the progressive cache to add the parameters I want to the cache id?
Workarounds such as sending the full category tree and doing it with ajax will not be accepted.
One thing you could look at is ContentModelArticle in the back end. You will notice that cleanCache()
forcibly clears the content modules that could be impacted by a save or create.
protected function cleanCache($group = null, $client_id = 0)
{
parent::cleanCache('com_content');
parent::cleanCache('mod_articles_archive');
parent::cleanCache('mod_articles_categories');
parent::cleanCache('mod_articles_category');
parent::cleanCache('mod_articles_latest');
parent::cleanCache('mod_articles_news');
parent::cleanCache('mod_articles_popular');
}
I've always thought this was a sledge hammer/kludge since it doesn't let the webmaster control whether or not to do this, but you could do something along the lines of making a custom cleanCache() for your model.

Get a list of Active Directory Users along with their Full Name and Email

I need to retrieve a list of Active Directory users and their attributes using Delphi 2010.
I've seen a few similar questions on SO (e.g. Delphi - Find primary email address for an Active Directory user), but they all seem to require the user name before any additional information can be retrieved.
I had written an article for [The Delphi Magazine] way back when..... if you have access to a backlog of those magazines, it's in issue no. 62 (October 2000) - unfortunately, it seems those back issues aren't available for purchase anymore :-(
It's too long of an article and a code sample to post here.... basically it's about wrapping the IDirectorySearch interface in a nicer Delphi-like shell. You pass in a base container where to search, you define an LDAP filter, and you define a set of attributes you're interested in - then you search and get back basically an enumerator for the results, which you can get one by one.
In the end, I discovered TJvObjectPickerDialog, part of JVCL. It wraps the Windows Select Object dialog and does everything I need with very little coding. Just set the required properties and call execute. The selected user objects are returned along with the attributes that you set in the 'Attributes' property.

CakePHP, organize site structure around groups

So, I'm not quite sure how I should structure this in CakePHP to work correctly in the proper MVC form.
Let's, for argument sake, say I have the following data structure which are related in various ways:
Team
Task
Equipment
This is generally how sites are and is quite easy to structure and make in Cake. For example, I would have the a model, controller and view for each item set.
My problem (and I'm sure countless others have had it and already solved it) is that I have a level above the item sets. So, for example:
Department
Team
Task
Equipment
Department
Team
Task
Equipment
Department
Team
Task
Equipment
In my site, I need the ability for someone to view the site at an individual group level as well as move to view it all together (ie, ignore the groups).
So, I have models, views and controls for Depart, Team, Task and Equipment.
How do I structure my site so that from the Department view, someone can select a Department then move around the site to the different views for Team/Task/Equipment showing only those that belong to that particular Department.
In this same format, is there a way to also move around ignoring the department associations?
Hopefully the following example URLs clarifies anything that was unclear:
// View items while disregarding which group-set record they belong to
http://www.example.com/Team/action/id
http://www.example.com/Task/action/id
http://www.example.com/Equipment/action/id
http://www.example.com/Departments
// View items as if only those associated with the selected group-set record exist
http://www.example.com/Department/HR/Team/action/id
http://www.example.com/Department/HR/Task/action/id
http://www.example.com/Department/HR/Equipment/action/id
Can I get the controllers to function in this manner? Is there someone to read so I can figure this out?
Thanks to those that read all this :)
I think I know what you're trying to do. Correct me if I'm wrong:
I built a project manager for myself in which I wanted the URLs to be more logical, so instead of using something like
http://domain.com/project/milestones/add/MyProjectName I could use
http://domain.com/project/MyProjectName/milestones/add
I added a custom route to the end (!important) of my routes so that it catches anything that's not already a route and treats it as a "variable route".
Router::connect('/project/:project/:controller/:action/*', array(), array('project' => '[a-zA-Z0-9\-]+'));
Whatever route you put means that you can't already (or ever) have a controller by that name, for that reason I consider it a good practice to use a singular word instead of a plural. (I have a Projects Controller, so I use "project" to avoid conflicting with it.)
Now, to access the :project parameter anywhere in my app, I use this function in my AppController:
function __currentProject(){
// Finding the current Project's Info
if(isset($this->params['project'])){
App::import('Model', 'Project');
$projectNames = new Project;
$projectNames->contain();
$projectInfo = $projectNames->find('first', array('conditions' => array('Project.slug' => $this->params['project'])));
$project_id = $projectInfo['Project']['id'];
$this->set('project_name_for_layout', $projectInfo['Project']['name']);
return $project_id;
}
}
And I utilize it in my other controllers:
function overview(){
$this->layout = 'project';
// Getting currentProject id from App Controller
$project_id = parent::__currentProject();
// Finding out what time it is and performing queries based on time.
$nowStamp = time();
$nowDate = date('Y-m-d H:i:s' , $nowStamp);
$twoWeeksFromNow = $nowDate + 1209600;
$lateMilestones = $this->Project->Milestone->find('all', array('conditions'=>array('Milestone.project_id' => $project_id, 'Milestone.complete'=> 0, 'Milestone.duedate <'=> $nowDate)));
$this->set(compact('lateMilestones'));
$currentProject = $this->Project->find('all', array('conditions'=>array('Project.slug' => $this->params['project'])));
$this->set(compact('currentProject'));
}
For your project you can try using a route like this at the end of your routes.php file:
Router::connect('/:groupname/:controller/:action/*', array(), array('groupname' => '[a-zA-Z0-9\-]+'));
// Notice I removed "/project" from the beginning. If you put the :groupname first, as I've done in the last example, then you only have one option for these custom url routes.
Then modify the other code to your needs.
If this is a public site, you may want to consider using named variables. This will allow you to define the group on the URL still, but without additional functionality requirements.
http://example.com/team/group:hr
http://example.com/team/action/group:hr/other:var
It may require custom routes too... but it should do the job.
http://book.cakephp.org/view/541/Named-parameters
http://book.cakephp.org/view/542/Defining-Routes
SESSIONS
Since web is stateless, you will need to use sessions (or cookies). The question you will need to ask yourself is how to reflect the selection (or not) of a specific department. It could be as simple as putting a drop down selection in the upper right that reflects ALL, HR, Sales, etc. When the drop down changes, it will set (or clear) the Group session variable.
As for the functionality in the controllers, you just check for the Session. If it is there, you limit the data by the select group. So you would use the same URLs, but the controller or model would manage how the data gets displayed.
// for all functionality use:
http://www.example.com/Team/action/id
http://www.example.com/Task/action/id
http://www.example.com/Equipment/action/id
You don't change the URL to accommodate for the functionality. That would be like using a different URL for every USER wanting to see their ADDRESS, PHONE NUMBER, or BILLING INFO. Where USER would be the group and ADDRESS, PHONE NUMBER< and BILLING INFO would be the item sets.
WITHOUT SESSIONS
The other option would be to put the Group filter on each page. So for example on Team/index view you would have a group drop down to filter the data. It would accomplish the same thing without having to set and clear session variables.
The conclusion is and the key thing to remember is that the functionality does not change nor does the URLs. The only thing that changes is that you will be working with filtered data sets.
Does that make sense?

Resources