No. This package doesnt include any update option.

James

HI Tony and everybody else,

The newest version (2.1.0b1) supports updating of users. As the version number implies, it's beta, but should work OK. Please provide feedback.

Hi James,

Thank you for this update, very handy!

I tried it out last night and have two comments:

1. Both the username and email address fields are needed for a successful import (I was at first just trying to update the username and another date field).

2. The date attribute I uploaded was in European format (ie dd/mm/yyyy), however the attribute ended up updating to US format. I am pretty sure I have the correct configs right, but if you are checking for that perhaps I did something wrong?

Thanks,
David

Hi.

1. If you're trying to update the username you'll need the email address for a key. If you just want to update the date field based in the username as a key then that should only require the username.

It's a bit hard to understand. Specifics and screenshots would help.

2. It uses strtotime, which is a php function and I believe is locale aware. It's best to remove all ambiguity and use a date like yyyy-mm-dd

Best,
James SHANNON

Sent from my phone

> On 23 avr. 2014, at 21:02, concrete5 Community <discussions@concretecms.com> wrote:

Thanks James,

The yyyy-mm-dd format worked.

My specific problem however is that I need to be able to export a user database so a third party can modify some fields (membership renewals processed manually) and then reupload the .csv

So if the renewal was end of financial year, Concrete5 exports the date fields in the format "30/06/2014".

Ideally I would like to have this as simple as possible so no mistakes could be made, but like I said, it is possible I haven't covered all the config variables in site.php for European style dates.

Concrete5 in general, going by these forums, is yet to have a simple all-encompassing solution that nicely handles strtotime AND the jquery datepicker used.

Thanks for the very quick reply though! I will keep investigating on my end.

David

Hi.

So it looks like strtotime isn't locale-dependent. Seehttps://php.net/manual/en/function.strtotime.php#100144... for an explanation, plus some tricks to getting it to work (specifically, " Forward slash (/) signifies American M/D/Y formatting, a dash (-) signifies European D-M-Y and a period (.) signifies ISO Y.M.D. ").

Personally, having worked with Europeans from the US, and with Americans from Europe, I've found that it just prevents a lot of headaches to use a non-ambiguous date format.

So other than tweaking the date before uploading (which would be pretty simple in excel), I don't know if there's much that can be done short of rewriting PHP's strtotime() or putting a layer on top of it.

James

Thanks for the definitive answer. The extra step in excel won't be such a huge issue, you are right.

Related issue: can you re-upload the entire list of users with some new ones thrown in and have it ignore the existing users?

I see that you can choose to force the upload to ignore them and continue, I wonder if there is a way to set that as a default.

Isn't that just implicit in the preview step? Ie, you preview and it points out that there are duplicates, and then you go to the next step which ignores those "errors"?

Also, assuming that the users haven't changed and you're trying to actively avoid importing those changes, why not just import and let it update the existing users?

Yeah, current active users mau have made changes so we can't overwrite them. But otherwise , we can do as you say. Thanks.