Group Report 4 12 Comments

Over the past two weeks we have completed python calls that tie into the PHP Sugarcrm API. We have moved on to making the function that the end user will directly interact with. In other words we are now in the process of making our own API the end user will interact with. This will be an object oriented API as opposed to the more procedural Sugarcrm API. From this we should be able to provide a god jumping off point for those who wish to interact with a Sugarcrm server in python.

We have also decided to rethink the way we are handling our unit testing. We wanted to try to reduce the footprint that the tests were having in the module as well as simplify their use. We decided to try to move them to their own module or combine them all into one, or both. This has not worked out all that well so far but work continues in the effort to get it sorted out. Our plan now will be to implement a more in depth and robust method of unit testing directly into the functions themselves as opposed to creating separate cases for unit testing. This will add a greater ease of use, allowing test cases on functionality to be done quickly, but also increase the efficiency of our sugarcrm.py class itself.

Another issue that our group has come into is this issue with relationships as I'm sure many of us have already stated. Our main problem with relationships was trying to figure out what relationships related to each other as it's not inherently clear how to initially relate the fields and modules together. However, I think now we have some idea of what to look after the code review that we had today and are going to look about implementing that functionality as one of the last major additions that our sugarcrm python needs.

Finally, our group talked about what future goals we should have in mind after we complete necessary functions in the sugarcrm python class. We talked about implementing a possible query class, which would generate SQL syntax making it easier on the user. Possibly add more functions that do not exist in the sugarcrm API at the moment, but functions that increase the efficiency of the sugarcrm API inherently. Also we are going to try and implement a dynamic way of creating functions as newer versions of sugarcrm become available, as a means of getting around adding functions by hard coding them into the code.

The last thing our group did today, was assign roles for the coming weeks to focus our time on certain activities. Andrew will continue working on the API, Ian and Jason on the wiki, and Kan and Erik working on getting unit testing up and running.