In a fresh install of OA with default settings, the first user I create has uid of 3.
If I cancel the account using the operation at the end of the row, the next uid will be uid+2.
If I cancel the account by checking the box and using the dropdown at the top, the next uid will be uid+3.

I can't think of anything in my OS that could make this happen, but it is somewhat hardened. Running on RHEL7 with apache, php55, and mariaDB.

Comments

soyokaze created an issue. See original summary.

Argus’s picture

Argus CreditAttribution: Argus commented

If you install a default Drupal this doesn't happen?

soyokaze’s picture

soyokaze CreditAttribution: soyokaze commented

Yesterday I had a mental block when I couldn't think of a good testing step to validate the rest of my system, so thanks for the suggestion :)

I just installed core 7.44 with everything else remaining exactly the same. The first user I created had uid 2 like normal, but the rest of the users skip a uid.

My testing is like scenario 3 in the original report (using the checkbox and dropdown to cancel the account), there is no 'end of row' option to cancel an account in drupal core.

Are you thinking this is an issue with core or an issue with my setup? Maybe the user module?

soyokaze’s picture

soyokaze CreditAttribution: soyokaze commented

I don't know why I haven't seen this before, but it looks like this is the way it is supposed to be. the uid is incremented every time db_next_id is run, not just for the uid. db_next_id runs for every batch job, and canceling accounts is (apparently) a batch job. I suspect OA or one of the modules that are a part of OA uses this function with the changes to the use cancel functions. I haven't looked to deeply into that part. I am also sure that canceling a user is not the only place db_next_id runs. It was just a repeatable test.

So, for anyone looking at a similar issue, I think this is the way it is supposed to be. I saw uids over 3000 after only testing the site for a few weeks.

Can anyone confirm that this is correct behavior?

mpotter’s picture

mpotter CreditAttribution: mpotter at Phase2 commented
Category: Bug report » Support request

You should probably try this on a plain Drupal install, or a plain Panopoly install. I'm not aware of any changes made by Atrium that would change the default Drupal behavior.

If plain Drupal/Panopoly does it like this then you'll probably need to post the issue in the appropriate issue queue. I can only help with this if you find some code in Atrium that needs to be changed.

soyokaze’s picture

soyokaze CreditAttribution: soyokaze commented
Status: Active » Closed (works as designed)

I'm just going to call this one closed. I'm pretty sure this is normal behavior after reading through some of the core code. I've just never scrutinized the user cancel or batch operations to see this happen before.

I also suspect the reason I noticed this in the first place was because the effect was compounded greatly by some custom code that has since been simplified and is therefore not a core or OA issue.

It was a bug in my code, but my test case outlined above was invalid for the bug that I fixed.

Thank you guys for looking.