Project

General

Profile

Actions

User story #2033

closed

userManagement PT : Make the name and password fields optionnal

Added by Matthieu CERDA over 12 years ago. Updated almost 12 years ago.

Status:
Released
Priority:
1
Assignee:
Matthieu CERDA
Category:
Techniques
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

userManagement PT : Make the name and password fields optionnal


Related issues 1 (0 open1 closed)

Is duplicate of Rudder - Bug #1939: User Management: Deleting user requires name, password, password frequency check and shell.RejectedMatthieu CERDA2011-10-13Actions
Actions #1

Updated by Matthieu CERDA over 12 years ago

  • Status changed from New to Pending technical review
  • % Done changed from 0 to 100

Applied in changeset commit:77e248c19cdf7ee2252b0b740e83c0dc832a2b0f.

Actions #2

Updated by Jonathan CLARKE over 12 years ago

Applied in changeset commit:ac9046d23a0bd773d041fe150ef9ddf2a86e56d3.

Actions #3

Updated by Nicolas CHARLES about 12 years ago

  • Status changed from Pending technical review to Discussion
  • % Done changed from 100 to 80

This implementation looks highly dubious.
The nameopt variable is defined only if nos is set, so at the second iteeration
However, nothing prevent the command from being run on the first iteration
I believe that it tries to create user $(useropt) on the first run ...

Actions #4

Updated by Matthieu CERDA about 12 years ago

  • Status changed from Discussion to Pending technical review
  • % Done changed from 80 to 100

Applied in changeset commit:3e477cbaa85d047a4948119acc7631e4aa151d4d.

Actions #5

Updated by François ARMAND about 12 years ago

Applied in changeset commit:6b0417e55d27e8f4bd876d8982bd1efddde32781.

Actions #6

Updated by Matthieu CERDA about 12 years ago

This was broken since 2011-11-10 18:24, meaning the 2.3.3 release.

Actions #7

Updated by Jonathan CLARKE about 12 years ago

Matthieu CERDA wrote:

This was broken since 2011-11-10 18:24, meaning the 2.3.3 release.

I don't understand: this bug is marked as targeted for 2.3.3 - does this mean it was broken and fixed in the same release? So in fact the bugged code was never released?

Also, can you please explain the behaviour that was expected, and the behaviour that actually happened, and how this was wrong?

Actions #8

Updated by Matthieu CERDA about 12 years ago

The PT was broken between 2011-11-10 18:24 and 2012-01-12. It is present in any release done during this interval.

The unexpected behaviour was that if someone attempted to create an user without a password or without a full name, garbage was outputted so the user creation failed. (An error reporting is done though).

The expected behaviour is now that creating a user without a password or a full name has no impact on the behaviour of the PT : It will simply ignore these informations and go on with a no full name or without attempting a password update.

Actions #9

Updated by Nicolas CHARLES about 12 years ago

  • Status changed from Pending technical review to 10

This does look valid from a technical point of view, with my limited admin skill, thank you Matthieu. I like the usage of

"showtime" expression => isvariable("nameopt[1]");

Actions #10

Updated by Jonathan CLARKE almost 12 years ago

  • Status changed from 10 to Released
Actions

Also available in: Atom PDF