New permission 'Export data'

Note I just emailed the dev list & posted on chat to solicit feedback

Enhances best practice for data protection and improves compliance for GDPR in my view.

If the permission is export data, I'd expect this means it overlays existing data access permissions, ie you can only export data which you'd have access to?

So: a user with export data can only export custom data if they also have access custom data, and can only export contacts if they also have view all contacts, or if other contact permissions are in play then they can only export those contacts they could view.

I suspect this is implicit (current user dictates access to data via API) but it'd be good if it's explicitly defined, so the "export data" permission doesn't allow for any bypass of access controls.

@xurizaemon correct - the export data permission does not increase permissions to access data. Not having it reduces permissions - specifically on the 2 UI screens mention - search export & report export to csv/pdf

One part of my brain thinks that is a good permission. The other part thinks if I dont have the permission I will probaly find it quite easy to export the data anyway. E.g. I could create a letter (pdf) and then misuse the tokens to export the data I want in csv format. Or is the print letter option alos going to be disabled at the contact dashbboard and search screen?

fair comment - the concerns I've heard have more been about the bulk access & ease of getting data out & the fact no activity or record is created - it's definitely not going to give you a fully audited system just a little more control

Take a look at the original CRM-16326 @jaapjansma, it helps clarify the why. More about encouraging CiviCRM use by preventing convenient bulk export than about restricting access to the data.

(Which might or might not be the reason it's happening today!!)

Whilst I like the concept (especially for GDPR concerned organisations as this is a common requirement) I have some small concerns about us moving in a direction which undermines / splits conceptually the UI from a real data (i.e. API) level execution (as Jaap mentioned).

We already have some issues with this where for example I can download attachments if I have the direct URL and we may give the false impression that we are blocking bulk API actions in some way.

We should probably make it clear in the description of the permission that this does not stop people using API and other methods to download data in bulk, but will restrict access to the export screens only. I think perhaps thats an acceptable trade off for what is a useful split.

This probably steps from the fact that we mix CMS permissions and ACLs in an inelegant way - and don't really separate our concerns...

i.e. currently we have:

ACLs that kinda do some of give CRUD control over entities at an entity level eg: Create data in X custom fields group (but also update at the same time)
We seem to then provide override permissions to those CRUD operations to make it easier to configure the system (i.e. Access all custom data) - which is a mixture of different CRUD operations.

But it would be better to be specific:

ACL's that specifically target CRUD operations separately for each entity (in sensible groupings).
Permissions perhaps don't do CRUD, but enable and disable access to whole features/modules/extensions/components.

In general, just whilst we are talking about permissions - I would also push that our roadmap should take seriously a more towards more granular permission control as currently there is a few cases where one permission does a lot of different things making it hard to split out Civi for different teams in an org, and perhaps a clearer articulation of the relationship between permissions and ACL's.

Just some thoughts as we think for the future...

As a matter of convenience, it makes sense, as described in the original JIRA issue with regard to getting new users to keep working in civicrm instead of reverting to their old Excel habits:

We see that with the export button enabled lots of people tend to export and mail each other the very documents we were happy with to abandon with civicrm.

Obviously it doesn't add any real limitations on data export; if you can make the report you'll be able to scrape the data, print to pdf, export to html, copy/paste into Excel, etc. I suggest the perm description should make it clear that this is for convenience only.

Good idea, I've implemented something similar in an ad-hoc way for a customer in the past.

I also share the concerns, perhaps labelling the permission as "Access Export UI" is more accurate.

Hey Eileen and all,

Jamie McClelland created an extension that restricts permissions to export. Check it out here: https://github.com/progressivetech/net.ourpowerbase.exportpermission As groups are concerned about digital security, e.g. disgruntled volunteer or employee, or preventing download of sensitive info,,a feature like this was needed.

Nice extension, works the same way mine did. I'd support moving this into core with updated label, it's a very small change (just adding a permission and implementing hook_civicrm_searchTasks) and of generally beneficial improvement to most implementations. I guess it'd need some documentation and tests as well ....

I'm not fully convinced that this belongs in core, mostly due to the concerns expressed by @jamienovick1 and because it is (and has been) so easily implemented in an extension. What are the benefits of having it in core as opposed to an extension?

It IS a common feature of competing CRMs, but I agree with concerns above. Perhaps the compromise position is to review either the @AlanDixon or @jamie extension for distribution through the extensions directory?

So - Just to reiterate I think this is fine to bring this into core if we make it make the subtext of the permission super clear that this doesn't really stop people using other methods to download data in bulk i.e. reports or direct API. If it's not a huge overhead to maintain I think it would certainly be something that is another positive point in the fight against other products...

Maybe we could even call the permission "Access export search action", rather then "Export data" to make it clear its just about access to the search action to export... i.e.

CiviCRM: Access export search action
This permission allows users to access the export data search action. Note that users without this permission may still be able to download data in bulk through other means such as reports.

Maybe too wordy?

I'm going to try out Jamie's extension - I'm leaning towards the extension approach

I think this comment makes a lot of sense

"It IS a common feature of competing CRMs, but I agree with concerns above. Perhaps the compromise position is to review either the @AlanDixon or @jamie extension for distribution through the extensions directory?"

Ok just to close the loop here. Firstly

thank you ALL for your input on this. You have moved my thinking on it & I am now of the opinion that this is fine as an extension
I have offered to review the extension as I think it should be published & have put up a PR against it to bring it up to date with the great work @mattwire did making this less painful
I feel like an interesting extension would be to actually expose the various link options & allow people to permission them rather than be export specific. I don't have a reason to do this right now but something to ponder
if there is interest at WMF I will look to extend the hook to support report links too (although part of me thinks our reports infrastructure is getting towards the end of it's useful life)

So summary - input has been very helpful - going forwards I will recommend https://github.com/progressivetech/net.ourpowerbase.exportpermission for anyone wanting to do this.

closed

New permission 'Export data'

Child items ...

Activity