Project

General

Profile

Actions
Copy link

User story #2033

closed

userManagement PT : Make the name and password fields optionnal

Added by Matthieu CERDA about 13 years ago. Updated over 12 years ago.

Status:
Released
Priority:
1 (highest)
Assignee:
Matthieu CERDA
Category:
Techniques
Target version:
2.3.3
Pull Request:
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 open — 1 closed)

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

Updated by Matthieu CERDA about 13 years ago

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

Applied in changeset commit:77e248c19cdf7ee2252b0b740e83c0dc832a2b0f.

Actions
Copy link
 #2

Updated by Jonathan CLARKE about 13 years ago

Applied in changeset commit:ac9046d23a0bd773d041fe150ef9ddf2a86e56d3.

Actions
Copy link
 #3

Updated by Nicolas CHARLES almost 13 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
Copy link
 #4

Updated by Matthieu CERDA almost 13 years ago

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

Applied in changeset commit:3e477cbaa85d047a4948119acc7631e4aa151d4d.

Actions
Copy link
 #5

Updated by François ARMAND almost 13 years ago

Applied in changeset commit:6b0417e55d27e8f4bd876d8982bd1efddde32781.

Actions
Copy link
 #6

Updated by Matthieu CERDA almost 13 years ago

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

Actions
Copy link
 #7

Updated by Jonathan CLARKE almost 13 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
Copy link
 #8

Updated by Matthieu CERDA almost 13 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
Copy link
 #9

Updated by Nicolas CHARLES almost 13 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
Copy link
 #10

Updated by Jonathan CLARKE over 12 years ago

  • Status changed from 10 to Released
Actions
Copy link

Also available in: Atom PDF