3738: Expose UI to show extra_data in review

vlo****@gmai***** (Google Code) (Is this you? Claim this profile.)
What version are you running?

What's the URL of the page containing the problem?

What steps will reproduce the problem?
1. Have an extension (or python API call) add extra_data to the review

What is the expected output? What do you see instead?
I would love a way to examine the extra_data for debugging purposes.

Please provide any additional information below.
It would be nice if there was UI for review drafts, file attachments & on any other pages where a resource has a visual display component.
#1 vlo****@gmai***** (Google Code) (Is this you? Claim this profile.)
Extending the concept a little bit, it would be cool if the API/extension would have to explicitly show values in the extra_data.

For example:
'extra_data': { '_visible': ['key1'], 'key1': ['a', 'b'], 'key2': 'something'})

The UI would only show the array for key1.
key2 would be hidden.

If key1 was itself a dictionary, then it would need a '_visible' key that would define the keys visible at that level.
#2 david
I don't think we want to add visibility for extra_data to the standard UI, because internally code will use it for state, and extensions can add whatever they like (and we really expect that if an extension wants to add things to the UI, that they'll do so for each explicit thing they want to add).

That said, for debugging purposes, we should add fields in the database admin pages. We do already have this for the comment objects, and it should be pretty easy to add for ReviewRequest, Review, and other objects that have extra_data fields.
  • +Component-Admin
#3 vlo****@gmai***** (Google Code) (Is this you? Claim this profile.)
Something to keep in mind is that developing plugins is a lot of effort (at
least as compared to the Python API).  Exposing a friendly UI for data
marked as "visible" can reduce the need for developing a custom UI.

For example, I need to store the branch the diff is based on (so that my
diff computation is correct).  If the data were exposed, the user could
change this value without having to run rbtools on their machine
(currently, they can do everything via git pus and rbtools stuff is done in

#4 adriano

I'm going to try working on this one.
- Adriano

#5 brennie
  • +adriano
#6 chipx86
  • -New
  • +Release-2.0.x