Generic Setup Tarball import with base profile

Plone Support Add-on Development
1

i tried to add a role to my plonesite (4.3.9) that is also displayed in the sharing tab and found out that this can't be done TTW.
either generic-setup (sharing.xml) or registering a persistent utility (what plone.app.workflow does for sharing.xml files) is needed.

so i tried to follow the path of least resistence (no package needed) and created a tarball for importing that consists of the following 2 files:

rolemap.xml

<?xml version="1.0"?>
<rolemap>
  <roles>
    <role name="Notified"/>
  </roles>
  <permissions>
    <permission name="plone.app.blob: Add Blob" acquire="True">
      <role name="Notified" />
    </permission>
  </permissions>
</rolemap>

sharing.xml

<?xml version="1.0"?>
<sharing
    xmlns:i18n="http://xml.zope.org/namespaces/i18n"
    i18n:domain="plone">
  <role
      id="Notified"
      title="gets notified"
      permission="Plone Site Setup: Overview "
      i18n:attributes="title"
      />
</sharing>

however - this screwed up my whole site (of course there is a backup :wink:

all local roles (Editor, contributor, etc) where missing. all permissions have been reset (join form was visible, zope root manager user had no permission to request passwords for existing users, etc)

it seems the base-profile (never really understood this concepts :frowning: and docs didn't help me much here) is missing for generic setup when importing the tarball and it does not apply these changes on top of the current settings but replaces all settings with the ones provided in this file.
in contrary - using these files in the the default or upgrade profile of an existing packages works fine.

where is the difference?

how can i make the tarball import work?

is there a way to fix my broken plone-site (by running a certain profile that restores the default roles and permissions of a plone site)?

is there a way to do a tarball import without

2

Doesn't answer your questions but can I ask.why you want extra role on the sharing tab? I've found several times where the need for a new role was due to not understanding roles in the sharing tabs are really permissions and groups are the best thing to represent roles.

3

sure you can @djay.
in this case we're using collective.contentrule.mailtorole to inform certain people about new content that has been added to certain areas on the page.
we first tried to get this done using the reader role but found many cases where not all people having the View permission should actually get an email.
this is why we introduced a new role "Notified" and site-admin can grant this rule to the users/groups that shall get a notification mail for new content in this area.

4

@frisi So what you are after is a convinient way for an admin to select a bunch of people to get notified on changes to certain content (like sub items being added). That does seem like a misuse of a role as a role is to do with access, not notification.
Probably there is a plugin that exists already that does this for you via content rules. (had a look at https://github.com/collective/collective.watcherlist but quick look it seems to be integrator only).
You could argue that it should be generically possible to register lists of users interested in an item out of the box in core plone. Or that it should be generically possible to add new roles more easily TTW but as I said, in most cases it would be missued and make sharing more confusing as it wouldn't be clear what permission you are giving with any new role.

5

It has been a very long time that I have read the complete "GenericSetup" documentation. Maybe, I no longer remember all the details correctly.

A "base profile" means: use this profile for the complete "GenericSetup" configuration of the portal, i.e. ignore everything already existing. An "extension profile" means, integrate this profile into an existing profile, partially extending/overriding the existing profile.

"GenericSetup" has three main use cases:

  1. define the complete configuration externally in the file system
  2. Transport an existing portal configuration into a new portal (e.g. in order to get changes from a development portal into a prduction portal)
  3. allow Add-On developers to extend/override an existing portal

The first use case is targeted by the "base profile"; the third by the "extension profile". I think, tar file export/import was designed for the second use case.
Apparently, it partially behaves like a "base profile".

I have never liked the tar file export - as it is much more restrictive than the import. Rather than tar file export/import, I have always preferred to update the configuration via a script. I have a general "import_gs" script that can import profiles or individual profile steps. And in all my Plone installations, there is always at least one custom Add-On designed for customizations. This Add-On gets additional profiles, if required.

6

Code is here: https://github.com/zopefoundation/Products.GenericSetup/blob/1.8.3/Products/GenericSetup/tool.py#L606

manage_importTarball calls self.runAllImportStepsFromProfile(None, True, archive=tarball)

The second argument means purge_old=True is used in the runAllImportStepsFromProfile call:

So tarballs are currently loaded in purge mode: all else is removed, depending on how the various import steps are implemented.

I did change some things the last years, so I checked how it was in a very old 1.4.0 release, but there it is the same:

In 1.8.2 I have split the overly complex Import tab into three tabs: Import (for importing a full profile), Advanced Import (the original manage_importSteps url leads to this tab), and Tarball Import.
A nice addition would be to have an option 'purge' on the tarball importl, which would default to True, but could be switched off.

The only way to undo the large changes, would be the Undo tab. Otherwise, you can check the Snapshots tab of portal_setup to see if a snapshot has been made recently.

1 Like
7

thanks @dieter and @mauritsvanrees for clarifying this so comprehensive.

@djay thanks for your input - when i'd try to solve this in a separate addon i'd re-use or depend on watcherlist or sthg similar and create a new content rule that can send emails to the watcherlist.