Export doesn't show orbeon/builder

[ebruchez]

Is this on purpose, or just because the builder app is in the resources provider?

[ebruchez]

We obtain the list of possible app/form/version triplets by calling the Form Metadata API, which doesn't return orbeon/builder. A quick hack to simply return it allows exporting Form Builder data, but it has the following issues:

• the Form Builder form definition is also exported!
• orbeon/builder shows on the Published Forms and Admin pages

For backward compatibility, we should not return orbeon/builder by default anyway.

• [ ] Q: Do we need a new parameter, or is there a combination of existing ones that we can use?
• [ ] make sure the Form Builder form definition is not exported
• [ ] make sure orbeon/builder doesn't show on the Published Forms and Admin pages
  • unless we want to let it show, so we can navigate to it? but weird to have it like other forms?
• [ ] Q: Does form-builder-permissions.xml matter?

[ebruchez]

Scenario: we want to handle orbeon/builder specifically for the export.

I am trying to understand again how permission parameters work with the Form Metadata API.

• Zip Export
  • explicitly pass all-forms=false
  • implicitly pass ignore-admin-permissions= false (the default), like for the Admin page
• Admin
  • implicitly pass all-forms=false (the default)
  • explicitly pass ignore-admin-permissions= false
• Published Forms
  • implicitly pass all-forms=false (the default)
  • explicitly pass ignore-admin-permissions= true

Reminder to myself: we have a distinction between:

• permissions associated with a form definition using the Form Builder UI or properties
  • those control access to a form definition and associated form data
• "admin" or Form Builder permissions, defined in form-builder-permissions.xml
  • initially, those were to control what form definitions users can create/edit in Form Builder
  • later, those same permissions were used to control what you can see in the Form Builder Admin page

    • 2906

Based on this:

• Zip Export
  • is considered an admin or superuser function
    • this was meant to mean "don't honor form permissions"
    • but it could still mean "honor admin permissions"
      • this would make sense, so that the export would match what you can see in the Admin page, the Export button being on that page
• Admin
  • Here, we actually show
    • forms for which there are admin operations available
    • but also forms for which there are no admin operations available, and which the current user can access with at least one permission such as create or read
• Published Forms
  • only show forms that the current user can access with at least one permission such as create or read

Bottom line:

• Zip Export uses the same parameters (adjusting for defaults) as the Admin page when calling the Fom Metadata API. This is good as this means you export at most what you see on the Admin page.
• The isInternalAdminUser parameter only impact reading/deleting form data, impacting the CRUD and Search APIs, but not the Form Metadata API.

Further tasks:

• [ ] when calling the Zip Export API, in order to export all forms, you need to have a user with role that allows accessing everything in form-builder-permissions.xml; add a parameter to allow exporting everything?

[ebruchez]

Options for orbeon/builder

• additional parameter to the Fom Metadata API to include orbeon/builder
• additional parameter to the Fom Metadata API to include "resource manager forms"
• implicitly, in the Zip Export code, know about orbeon/builder

Benefits and drawbacks:

• benefits
  • using the Fom Metadata API is more general
  • the Zip Export code uses the Fom Metadata API as well
• drawbacks
  • Form Builder is not "really" a form like the others.
  • if we list orbeon/builder in the Export dialog, we don't want to list it in the Admin page table (probably)

[ebruchez]

Case of app-based multitenancy: user has access to app acme, Form Builder data export should only export form data with app acme.