[SOLVED] CSV import - if you drop data it wipes all data in that list including other user's data

Status
Not open for further replies.

chozma

Member
Hi guys,

I'm so sorry for all the requests for support at the mo... I've been putting off the bug list my testers generated for me for too long. I'm finally in the mode for smashing through them. Hopefully there won't be many more, I am almost at the end of my list! ;)

I have an interesting behaviour with CSV import.

So with the CSV import if a user uploads a CSV and selects 'drop data' to 'yes', then it deletes all the data out of that table and replaces it with the new data. I expected it to only touch the user's data. Pretty much all of my lists only display data that belongs to a user. So as you can imagine it's not so cool when you log in the next day and realise someone else has made all your data disappear! :eek: :)

I'm not sure if this is an expected behaviour or not, I can see why it could be....

So I've tested this in a few situations. It seems to do it across all my tables. Some of my tables have list csv plugins that do data lookups etc but that doesn't seem to make a difference. A super-user and a registered user both get the drop option and make it happen. If the user doesn't select 'drop' it's all good and another user's data is not affected.

I'd be quite happy not to have the option to drop data for a user in the frontend or in fact any of the options. Just choose a file, click the button and away you go. Screenshot of the options I am talking about are attached.

So a quick fix might just be to get rid of all the options like you can do with CSV export.

What do you recommend guys?

Thanks,

hannah
x
 
I assume the csv import was never thought for multiple frontend users.

I think it would make sense to show the "Drop" only if the user has "Empty" list access (and I assume this would be not too complicated - Rob?Hugh?)
But to have import respecting prefilters/or use field/canEditrow etc...???

As a quick workaround you could hide the Drop button via CSS (this is no security means but may prevent accidental deletes)
 
I'm just testing a fix for this, as per Troester's suggestion, I'm trying that option to the canEmpty() permission on the list. So if you don't have the empty ACL, the option won't show. I'm also testing for it when at the start of the actual import, so make sure the drop_data input can't be spoofed.

-- hugh
 
Oh, and just to echo Troester's comment, I don't see us implementing a per-user drop feature which removes just that user's data. If it's something you really would find useful, we can have a look and see how tough it would be - I just had a quick look, and it might not actually be too hard. We could consider the "owner" to be the "or user" setting for "Edit Rows" access on that list, and just delete all rows with that column == the logged on user. So no need for additional settings. And it could use the existing list model row deletion, that would optionally delete any releated rows in joined tables.

But it's not something we'd do unless you REALLY wanted it.

-- hugh
 
Thanks Hugh. I'm about to copy across the new commit so will let you know how that goes once I've tested.

I think this is a really great and sensible suggestion by @troester. Thanks! :D

To be honest, I think it's dangerous to let users delete/drop their own data in this fashion and there's plenty of other ways they can clear records if they want to. :rolleyes: So no I don't see this as being something I'd REALLY want. The calendar fix is much more important to me and my users.
 
Ok, I've just done a test so this seems to be working fine.

Thanks for coming up with a really helpful solution so quickly. :)
 
It needed it. Just not something Id ever thought about, as I pretty much never allow front end CSV import for normal users, and if I do, I don't let them choose any options, I preset them.

-- hugh
 
Status
Not open for further replies.
We are in need of some funding.
More details.

Thank you.

Members online

No members online now.
Back
Top