yahoo-eng-team team mailing list archive

[Rob Cresswell <rcresswe@xxxxxxxxx>]

I'd assume this actually applies to any edit/update.

How would you suggest fixing this? Off the top of my head, all I could
think is doing another GET for the specific resource ID when the user
hits save, and then comparing that to the initial form values. Even
then, there would be a very slim margin where a CLI user could update
something, and it would increase the latency on form submit as you're
adding a second round trip to verify it on Horizons side.

I think ideally to avoid this, you'd likely need some form of locking
mechanism on the API side, so a Horizon user hits update and this
announces their intent to update to the service; then the CLI user may
receive a message along the lines of "this data is being manipulated by
<something_or_someone>, are you sure?"

** Changed in: horizon
       Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1596060

Title:
  Project panel doesn't handle race conditions for roles

Status in OpenStack Dashboard (Horizon):
  Opinion

Bug description:
  Suppose we have two users A and B. A uses Horizon and B uses the CLI.

  Sequence:
  1. User A opens the 'Manage Members' modal for Project X.
  2. User B uses the CLI to make changes to roles in Project X.
  3. User A saves changes made in the modal.

  Expected outcome: User A is either warned of User B's changes OR User A's changes only update the roles that User A modified.
  Actual outcome: User B's changes are completely overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1596060/+subscriptions