Forum Replies Created
Imagine you have some main entity e.g. Customer and then you can show a filterable/sortable column for each associated Group. You have 3 groups with IDs 1, 2 and 3.
To do that you have to join Group entity three times like that:MySQL1234567891011SELECTc.id,c.name,g1.data,g2.data,g3.dataFROMoro_customer cLEFT JOIN oro_customer_group g1 ON c.group_id = g1.id AND g1.id = 1LEFT JOIN oro_customer_group g2 ON c.group_id = g2.id AND g1.id = 2LEFT JOIN oro_customer_group g3 ON c.group_id = g3.id AND g1.id = 3
By doing that you now can work with three separate joins/aliases and create filter/sorter for each of them.
Of course, this is just a demonstration of the approach, but using it you may have a new column for each group, select some column and then add a filter a sorted using these new relations.
The easiest solution is indeed just make a copy of the original organization entity, call it e.g. AdvancedOrganization and then create separate extended model class called ExtendAdvancedOrganization – this way you will have your own independent organization and independent extended entity for it.
Pay attention that in this case new organization entity will not inherit built in organization related features like ACL, ownership etc.
But before that you may stop for a moment and think a little about two absolutely identical entities in your application (which looks like violation of SOLID). Maybe you can add extended boolean flag (e.g. isAdvanced) to the standard Organization entity and distinguish them in this way? Or set some organization as a special organization in the System Configuration and then use this reference to identify it? Or your custom organization logic can be emulated using standard Business Units?January 24, 2019 at 8:03 am in reply to: How much Experience is need for development Orocommerce #37967
Basic Symfony knowledge and some real life experience should be enough to start work with the Oro. Technically all Oro applications are just Symfony application with lots of additional features. In other words it is enough to know Symfony to understand structure of the application, but each new feature added by Oro will require some time to learn.
There are also other skills which are not mandatory, but highly recommended – these are general architectural skills (e.g. design patterns knowledge), general PHP coding skills, general DBMS knowledge etc. It is also highly recommended to know how to debug a PHP application (e.g. using xDebug). Everything else is just a matter of experience.
Oro applications are quite big and have lots of features, so it is very common for Oro developers to spend some time in the very beginning learning the architecture of these features.
To create new extended field you have to run you migration. Recommended way – execute oro:platform:update command. https://oroinc.com/orocrm/doc/2.6/dev-guide/cookbook/how-to-upgrade-to-new-version
As for another entity extended from Oro\Bundle\OrganizationBundle\Model\ExtendOrganization – it’s not recommended as each extended entity has to have it’s own extended classes. Otherwise application simply will not be able to create correct class aliases for extented entities.
> Do you know where I can find the email templates records?
They are stored at oro_email_template table, Oro\Bundle\EmailBundle\Entity\EmailTemplate entity.
> when I open the “oro_email_attachment” table, it’s empty, no export files records.
This table stores actual email attachments, not export files. Export files are generated on the fly when you are triggering export.
Featured categories and new arrivals are just two product subsets rendered as simplified product listings here and here. You may also check layout import oro_product_list used in both of these places and data providers featured_products and new_arrivals.
Configurable product is just a type of a standard product and information about product variants is rendered using either main product grid or product view page. By default product grid does not render product variants. Here is form rendered at product view page, pay attention to context variable product_type. You may also check oro_product_configurable_products data provider user to get information about configurable products at other bundles.
General recommendation – if you want to understand where each specific block is coming from then use layout tree at debug toolbar and debug block information. This article describes how to do that.
Products at front office are rendered in multiple places.
1) Main product grid (product listing, PLP etc) – renders grid of products that has pagination, filters and sorters. Datagrid used to render it is called frontend-product-search-grid and defined here: https://github.com/oroinc/orocommerce/blob/3.1.0-rc/src/Oro/Bundle/ProductBundle/Resources/config/oro/datagrids.yml#L736-L796 . This grid is extended by multiple listeners that adds additional filters, additional sorters, prices, shopping lists etc. This grid is usually rendered using oro_product_frontend_product_index route from this controller: https://github.com/oroinc/orocommerce/blob/3.1.0-rc/src/Oro/Bundle/ProductBundle/Controller/Frontend/ProductController.php#L18-L37 . This page is also used to render global search results.
2) Product view page (product information page, PDP etc) – renders information about one specific product. It is rendered using oro_product_frontend_product_view route from this controller: https://github.com/oroinc/orocommerce/blob/3.1.0-rc/src/Oro/Bundle/ProductBundle/Controller/Frontend/ProductController.php#L39-L103
3) Simplified product listing (e.g. Featured products at the root page) – renders short list of products without ability to paginate, sort of filter them. It is rendered using oro_product_list layout import. Here you may see how it is done: https://github.com/oroinc/orocommerce/blob/3.1.0-rc/src/Oro/Bundle/ProductBundle/Resources/views/layouts/blank/oro_frontend_root/featured_products.yml
Of course there are other places where products are rendered, but they are handled from other bundles. You may find them by checking an appropriate route and associated layout updates.
Please let me know if you have other questions.
Unfortunately there is no way to enable Data Audit on tags collection and it is not really a filed of an entity – it’s just virtual association.
Instead you may override (or decorate TagManager) and add new records to Data Audit tables for required entities.
If you require any further information, let me know.
Could you also attach a screenshot of a page with the element you’re trying to click? I’m asking that because standard email download link should look like https://*************/email/attachments/163, but not /export/download/…January 22, 2019 at 5:52 am in reply to: How to change only font-family in existing style.css file #37952
You may do pretty much the same for the out of the box themes as well – in the end all files are simply merged together and compiled.
Product bundle is responsible for storing of product related information (product itself, images, units etc) and managing it.
Bundle itself is participated in multiple business processes. Could you please clarify which business process do you have in mind?
I guess you’ve missed a permission. To make it work you should set Export entity records (id=oro_importexport_export) or Import entity records (id=oro_importexport_import) for the required role.
Please, try to do it and tell me if it helped.January 22, 2019 at 4:56 am in reply to: Migrations crash after adding FOSOAuthServerBundle #37948
Dylan, you may set a breakpoint in the autoloader and check when User class first time loaded – it has to happen after the OroEntityExtendBundle loaded class aliases.
We’ve faced such issues when somebody used User::class or User::<CONSTANT> notations as they trigger class autoloading. Solution is simple – use values instead.January 21, 2019 at 9:24 am in reply to: Migrations crash after adding FOSOAuthServerBundle #37942
> ‘Extend\Entity\EX_OroUserBundle_User’ which has the avatar property
Yes, this is the expected behaviour. OroExtendEntityBundle creates class aliases from Oro\Bundle\UserBundle\Model\ExtendUser to ‘Extend\Entity\EX_OroUserBundle_User and lools like some code is requesting User class before these aliases were loaded.
Btw, what priority did you set to FOSOAuthServerBundle in bundles.yml file?January 21, 2019 at 7:39 am in reply to: Migrations crash after adding FOSOAuthServerBundle #37940
Such error usually indicated that some bundle tries to load extended entity before aliases for extended classes in fact were loaded in OroExtendEntityBundle. Need to debug further to understand why it happened.
I’d recommend to register this bundle in the standard Oro way (i.e. using Resources/config/oro/bundles.yml, example https://github.com/oroinc/platform/blob/3.1.0-rc/src/Oro/Bundle/PlatformBundle/Resources/config/oro/bundles.yml) and set correct priority.