prashanth
(Prashanth)
September 2, 2019, 3:26pm
#1
Hello Team,
What is the best practice to move data between servers? For example: test and qa server.
In test you create roles, people and workflow items etc.
When you now point the studio to QA and run the scripts, it will create schema and not these objects. What is the recommended way to move these objects.
I know workflow can be exported/imported. But is there an alternate approach?
Regards,
Prashanth
krivopustov
(Konstantin Krivopustov)
September 6, 2019, 3:12pm
#2
Hi Prashanth,
Apart from exporting/importing data in JSON, you can roll out changes using SQL commands in 30.create-db.sql
script or in manually added update scripts.
The next CUBA feature release (7.2) will allow you to define security and reports at design time, so no data transfer will be required. You can track the progress in the issues:
opened 07:32AM - 04 Jun 19 UTC
closed 02:07PM - 25 Feb 20 UTC
type: enhancement
breaking-changes
state: fixed
comp: security
ver: 7.2.0
important
ver: 7.3.0
Added ability to define roles in the source code. New annotations are used for t… his purpose.
1) ```com.haulmont.cuba.security.app.role.annotation.Role```
Indicates that an annotated class is a "Role". Such a role will be available in the user interface if the application is running in the corresponding mode (the app property cuba.rolesStorageMode equals SOURCE_CODE or MIXED).
2) ```com.haulmont.cuba.security.role.EntityPermissionsContainer```
Defines permissions to access operations on an entity (read, create, update, delete).
3) ```com.haulmont.cuba.security.role.EntityAttributePermissionsContainer```
Defines permissions to access individual entity attributes.
4) ```com.haulmont.cuba.security.role.SpecificPermissionsContainer```
Defines specific permissions access.
5) ```com.haulmont.cuba.security.role.ScreenPermissionsContainer```
Defines screen access permissions.
6) ```com.haulmont.cuba.security.role.ScreenComponentPermissionsContainer```
Defines permissions to access screen elements.
The easiest way to determine the role in the application source code is to extend your class from AbstractRoleDefinition and mark it with ```@Role``` annotation. Usage example:
```
@Role(name = "My first role", isDefault = true)
public class MyFirstRole extends AnnotatedRoleDefinition {
@EntityAccess(entityClass = SomeEntity.class,
operations = {EntityOp.DELETE, EntityOp.UPDATE})
@EntityAccess(entityName = "app_SomeOtherEntity",
operations = {EntityOp.CREATE, EntityOp.READ})
@EntityAccess(entityName = "*",
operations = {EntityOp.CREATE})
@Override
public EntityPermissionsContainer entityPermissions() {
return super.entityPermissions();
}
@EntityAttributeAccess(entityClass = SomeEntity.class,
view = {"attr1", "attr2"},
modify = {"someAttribute"})
@EntityAttributeAccess(entityName = "app_SomeOtherEntity",
modify = {"someAttribute"})
@EntityAttributeAccess(entityName = "app_ThirdEntity", modify = "*")
@EntityAttributeAccess(entityName = "*", view = "*")
@Override
public EntityAttributePermissionsContainer entityAttributePermissions() {
return super.entityAttributePermissions();
}
@SpecificAccess(permissions = {"my.specific.permission1", "my.specific.permission2"})
@SpecificAccess(permissions = "*")
@Override
public SpecificPermissionsContainer specificPermissions() {
return super.specificPermissions();
}
@ScreenAccess(screenIds = {"myapp_SomeEntity.edit", "myapp_SomeEntity.edit"})
@ScreenAccess(screenIds = "*")
@Override
public ScreenPermissionsContainer screenPermissions() {
return super.screenPermissions();
}
@ScreenComponentAccess(screenId = "myapp_SomeEntity.browse",
deny = {"someGroupBox"},
allow = {"otherGroupBox", "commitButton"})
@Override
public ScreenComponentPermissionsContainer screenComponentPermissions() {
return super.screenComponentPermissions();
}
}
```
8) Defines security scope on a role definition #2428. The default security scope is Generic UI. You can set up security scope in a `@Role` annotation, e.g. creation a role for the REST scope
`@Role(name = "My first role", isDefault = true, securityScope='REST')`
Breaking changes:
* UserSession:
* Constructor `UserSession(UUID id, User user, Collection<Role> roles, Locale locale, boolean system)` signature changed to `UserSession(UUID id, User user, Collection<RoleDefinition> roles, Locale locale, boolean system)`
* Constructor `UserSession(UUID id, User user, Collection<Role> roles, Locale locale)` signature changed to `UserSession(UUID id, User user, Collection<RoleDefinition> roles, Locale locale)`
* Removed `addPermission` and `removePermission` methods. Use `UserSession#getJoinedRole` and `UserSession#setJoinedRole` with `RoleDefinitionBuilder` instead.
opened 08:45AM - 13 Oct 17 UTC
type: enhancement
important
To provide well-autotested product reports make possible to define them in the f… ollowing way
```
@Report(
name = "sample report",
defaultTemplate = "path/to/resource.xlsx",
...
)
@ReportTemplates(...)
@ReportParameters(...)
@ReportValueFormats(...)
@ReportRoles(...)
@ReportScreens(...)
public class SampleReport implements YargReport {
@ReportParameter
private Customer customer;
@ReportParameter(name = "order_param")
private Order order;
@ParameterTransformation(name = "customer")
protected Customer trasformCustomer(Customer customer) {
try (Transaction tx = persistence.createTransaction()) {
EntityManager em = persistence.getEntityManager();
return persistence.getEntityManager().reload(customer, "full-view");
}
}
@ParameterValidation(name = "order_param")
protected boolean validateOrder(Order order) {
return order.getState().equales(OrderState.VALID);
}
@ReportBand(name = "header")
public BandData headerBand(ParentBand parentBand) {
return BandData.of("customer_name", customer.getName());
}
@ReportBand(name = "customer_details", parentBand = "header")
public BandData detailsBand(ParentBand parentBand){
parentBand.getBandData();
...
}
}
```
---
Original issue: https://youtrack.haulmont.com/issue/PL-9860