[
https://issues.apache.org/jira/browse/OFBIZ-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Smits updated OFBIZ-6976:
--------------------------------
Description:
This is a placeholder issue.
Having correct data shipped with OFBiz is key to not only
# have a good operational state (meaning adopters can work with OFBiz out of
the box)
# have a good data set for demonstration purposes
# have a good data set to enable unit, system integration and acceptance testing
Re aspect 1:
This encompasses all security, system property and other seed data sets
Re aspect 2:
This encompasses all data records in the various DemoData.xml files. This kind
of data needs to be coherent from the perspective of the main internal
organisation (or the legal demo party) that operates the OFBiz implementation.
Re aspect 3:
The data set for this aspect encompasses all data under aspect 1 and 2.
With a good data set for demonstration purposes it is easier for potential
adopters (and their influencers) to see the added value of implementing OFBiz
in their company/organisation, while at the same time it helps developers to
understand the coherence between widgets, templates, services, functions and
the data counter parts.
Demo data sets should be grouped in accordance to the component load order (as
defined in e.g. component-load.xml). The first appearance of a data record of
the demo kind should also (as much as possible) be in accordance with where the
related entity is defined.
As an example:
The ProductStore entity is defined in the entity model for the Product
component (the product-entitymodel.xml). Thus any new demo record regarding
this should first appear in the ProductDemoData.xml file.
With the above we minimise the risk of duplication and dependency mismatches.
was:
This is a placeholder issue.
Having correct data shipped with OFBiz is key to not only
# have a good operational state (meaning adopters can work with OFBiz out of
the box)
# have a good data set for demonstration purposes
# have a good data set to enable unit, system integration and acceptance testing
Re aspect 1:
This encompasses all security, system property and other seed data sets
Re aspect 2:
This encompasses all data records in the various DemoData.xml files. This kind
of data needs to be coherent from the perspective of the main internal
organisation (or the legal demo party) that operates the OFBiz implementation.
Re aspect 3:
The data set for this aspect encompasses all data under aspect 1 and 2.
With a good data set for demonstration purposes it is easier for potential
adopters (and their influencers) to see the added value of implementing OFBiz
in their company/organisation, while at the same time it helps developers to
understand the coherence between widgets, templates, services, functions and
the data counter parts.
> Updating data sets
> ------------------
>
> Key: OFBIZ-6976
> URL: https://issues.apache.org/jira/browse/OFBIZ-6976
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS, ALL PLUGINS
> Affects Versions: Trunk
> Reporter: Pierre Smits
> Assignee: Pierre Smits
> Priority: Major
> Labels: Demo, configuration, test
>
> This is a placeholder issue.
> Having correct data shipped with OFBiz is key to not only
> # have a good operational state (meaning adopters can work with OFBiz out of
> the box)
> # have a good data set for demonstration purposes
> # have a good data set to enable unit, system integration and acceptance
> testing
> Re aspect 1:
> This encompasses all security, system property and other seed data sets
> Re aspect 2:
> This encompasses all data records in the various DemoData.xml files. This
> kind of data needs to be coherent from the perspective of the main internal
> organisation (or the legal demo party) that operates the OFBiz implementation.
> Re aspect 3:
> The data set for this aspect encompasses all data under aspect 1 and 2.
> With a good data set for demonstration purposes it is easier for potential
> adopters (and their influencers) to see the added value of implementing OFBiz
> in their company/organisation, while at the same time it helps developers to
> understand the coherence between widgets, templates, services, functions and
> the data counter parts.
> Demo data sets should be grouped in accordance to the component load order
> (as defined in e.g. component-load.xml). The first appearance of a data
> record of the demo kind should also (as much as possible) be in accordance
> with where the related entity is defined.
> As an example:
> The ProductStore entity is defined in the entity model for the Product
> component (the product-entitymodel.xml). Thus any new demo record regarding
> this should first appear in the ProductDemoData.xml file.
> With the above we minimise the risk of duplication and dependency mismatches.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
