Bug 31884 – Detection of user changes

Bug 31884 - Detection of user changes


Summary:	Detection of user changes

Status:	RESOLVED INVALID

Product:	UCS
Classification:	Unclassified
Component:	UMC - Domain management (Generic)
Version:	UCS 3.1
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	---
Assigned To:	UMC maintainers
QA Contact:

URL:
Keywords:

Depends on:
Blocks:	26215
	Show dependency tree / graph

Reported:	2013-07-03 15:08 CEST by Alexander Kläser
Modified:	2015-01-13 14:49 CET (History)
CC List:	2 users (show)

See Also:	35530 36700 29884 37119
What kind of report is it?:	---
What type of bug is this?:	---
Who will be affected by this bug?:	---
How will those affected feel about the bug?:	---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):	Usability
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Alexander Kläser

2013-07-03 15:08:59 CEST

Currently, user changes are detected by comparing the received values from the server and the current values set. This has several drawbacks and does not currently work (as the values CtxBrokenSession="0000" and CtxReconnectSession="0000" are not stored with the user object). It would be better to detect changes via manually changed values (via watch events on widgets).

Comment 1 Alexander Kläser

2013-07-03 15:09:35 CEST

With this, we could warn in case an edit operation is cancelled.

Comment 2 Florian Best

2013-11-12 08:44:12 CET

The bug is worse: It prevents users in "User Password Admins" to change a password of any user with the message "Access denied".

Bug #32978 comment 12

Comment 3 Alexander Kläser

2013-11-12 10:22:19 CET

(In reply to Florian Best from comment #2)
> The bug is worse: It prevents users in "User Password Admins" to change a
> password of any user with the message "Access denied".
> 
> Bug #32978 comment 12

… the error "Access denied" occurs as Ctx* values are sent along with the password changes.

Comment 4 Florian Best

2014-12-02 11:52:05 CET

I found another one for a user which doesn't have the posix option: "primaryGroup" and "$dn$" are changing.

d.getAlteredValues()
Object {primaryGroup: "cn=Account Operators,cn=Builtin,dc=ucs,dc=dev", $dn$: "uid=noposix,cn=users,dc=ucs,dc=dev"}

Comment 5 Florian Best

2014-12-02 23:39:06 CET

(In reply to Florian Best from comment #4)
> I found another one for a user which doesn't have the posix option:
> "primaryGroup" and "$dn$" are changing.
> 
> d.getAlteredValues()
> Object {primaryGroup: "cn=Account Operators,cn=Builtin,dc=ucs,dc=dev", $dn$:
> "uid=noposix,cn=users,dc=ucs,dc=dev"}
→ I found a bug which already reported this as external feedback: Bug #28383

Comment 6 Florian Best

2014-12-02 23:40:18 CET

(In reply to Florian Best from comment #5)
> (In reply to Florian Best from comment #4)
> > I found another one for a user which doesn't have the posix option:
> > "primaryGroup" and "$dn$" are changing.
> > 
> > d.getAlteredValues()
> > Object {primaryGroup: "cn=Account Operators,cn=Builtin,dc=ucs,dc=dev", $dn$:
> > "uid=noposix,cn=users,dc=ucs,dc=dev"}
> → I found a bug which already reported this as external feedback: Bug #28383
err, I meant Bug #37119

Comment 7 Alexander Kläser

2015-01-13 14:33:36 CET

As discussed, this way of detecting user changes will not be implemented.
(More details at Bug 36700)

Comment 8 Florian Best

2015-01-13 14:49:04 CET

As we don't fix this bug I created Bug #37532.