|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Mifos-issues mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-issues
I've just accepted your pull reqeust vishwas and I did digg in abit around the client/client search capababiliies.
From API perspective, I agree with you about the sql, its a powerful that would allow someone get the function they require (so long as they know the schema), but on the other side I think it breaks important quality of the api. Hiding complexity of system behind simple api calls.
So seeing that we use it for search term only at present - I think its over kill.
I think maybe we were thinking that there might be other ways it could be used to solve the wide range of 'search' that people would look for.
underHierarchy is fine as a api parameter and very useful for limiting search by office hierarchy (maybe parameter should be underOfficeHierarchy to be more clear)