Grid in OroCRM is a very convenient way to display information about all or few records of an entity. Default OroCRM has a lot of grids for different entities. OroCRM developers provided a useful and easy way to create grids for a custom entity or display some specific information for default entities.
Translation functionality is the most important part in localization and all applications should have it. OroCRM is not an exception and for this OroCRM team has developed a convenient functionality to work with translations without any difficulties.
If more detailed, OroCRM includes multiple languages and all translatable strings are defined in each bundle – we describe how it works in our article.
Localization or internationalization process means adapting a software to different languages, regional particularities and technical requirements of a target market. Well-designed software usually does not require code changes and deep engineering knowledges for localization or/and internationalization processes.
When we started working with OroCRM we have met problems with differences between Symfony core commands and OroCRM commands. That is why we decided to share this experience and prepared a list with the most common commands for everyday work with OroCRM such as cache clearing, migration, entities.
You may face with the situation when it is necessary to change a data grid for your OroCRM application. It is quite easy if you have already created your own bundle (we’ve described how to create a bundle in the previous article).
In this case, you can simply add few changes to datagrid.yml of this bundle. Nevertheless, sometimes we have to work with the bundles created by other developers or system bundles. And in those cases, we can use two ways: overwrite a full data grid configuration of the corresponded bundle or work with events of a listener.
As you may know, to add new data to Symfony bundles we can use migration scripts or it is also possible to use a fixture for this. However, we do not recommend to use the fixture if you need to change some configurations, alter table or insert any specific variable. Fortunately, OroCRM team has provided the solution for SQL queries in the migration scripts – we can use Insert, Update, Delete and other queries there.
Sometimes we can face with the different dependencies between the system bundles or bundles that are already created by other developers, and we will have to change the configuration for such bundles. Usually, it can be easily done because OroCRM has a quite good GUI interface. So, using GUI you will be able to change the configuration for any bundle. Nevertheless, pay attention that if you need the bundle for deployment to different servers, this way is not convenient. In case of deployment, you will need to add a description of the appropriate settings and it is also important to follow these settings in further development. The best way is to use the migrations scripts. In this article, we will show you how to change a config of a single entity in the bundle.
If you have ever developed the bundles for OroCRM, you should know that there is a need to add a button to different places. OroCRM developers can find many ways of adding different types of buttons on the pages. And our article will describe the general button’s types.
As you know, the possibility to schedule and execute some operations automatically in the background – it is a very important feature almost for all web applications. It allows to configure the system to check for the new updates, to make some maintenance operations, like logs cleaning, to run the synchronization processes between different systems etc. OroCRM has a built-in CRON daemon that gathers all CRON jobs from all the installed extensions and runs them in a scheduled time. The process of adding a new CRON job is quite easy.
Every OroCRM developer can face with a situation when there is a necessity to change a configuration for the entity config in the bundle. And it is no problem if we have an ability to remove a full bundle with the database tables. Recently, we’ve tried to change the ownership scope for the existing entity, but we could not delete the tables because there were a lot of data.