Tenant packages do not include ACLs

[GastonGonzalez]

Peregrine creates a content package definition when a tenant is created (i.e. sometenant-full-package-1.0.zip). Currently, the package definition does not set a value for AC handling. This poses a problem if content is migrated between Peregrine instances.

Use Case

1. There are two Peregrine instances: source and target.
2. A content package is created on the source system with filters for the all_tenant users (/home/users/tenants) and groups (/home/groups/tenants).
3. A tenant content package (i.e. a site) is rebuilt on on the source system.
4. The user/group package is imported into the target system.
5. The tenant content package is imported into the target system.

Actual Behavior

1. ACLs are missing on tenant content nodes

Expected Behavior

1. ACLs are preserved when imported into target system

Solution: Update package creation code to set AC handling to merge at time of package definition creation.

[reusr1]

@GastonGonzalez in my opinion this should not be fixed with the current package format. Packages in sling are installed at the oak level and therefore can always cause security and access issues due to the nature of their purpose. In our case we have to start thinking about a different format (and such a format could also be a good candidate for a sling contribution)

[GastonGonzalez]

@GastonGonzalez in my opinion this should not be fixed with the current package format. Packages in sling are installed at the oak level and therefore can always cause security and access issues due to the nature of their purpose. In our case we have to start thinking about a different format (and such a format could also be a good candidate for a sling contribution)

@reusr1 - You make a good point. Are you thinking of a simple DSL or JSON structure that describes the include/exclude paths, then layer on some application logic that inspects the current user's repository access to ensure that they are only able to read/write (export/import) data to which they have access?

[reusr1]

@GastonGonzalez I was thinking of a more generic dsl format where one can provide an implementation per project or provide more generic implementations as well

in our case we'd like to (as far as I know)

• define an owner of a site
• add other users to the site
• import or negotiate a tenant name for the site
• deal with the replication state of the content (do we have to replicate the content while importing or strip the replication state?)
• deal with asset version creation and asset metadata exports (are they necessary? do they need to be in the backup?)
• import the actual data into the tenant
• potentially deal with versions for each content node

it may also make sense to think about this format as streamable from one server to another (say you'd like to move a website from prod to stage for testing purposes or you are generating a site externally (markdown/other tool to site generation and need to apply a large body of content)

[ehdatheadwire]

Closing and relocating to: peregrine-cms/enhancements#50