You are correct. That was a side-effect of not handling the extra_data
field correctly, and I added a few more lines of code to `patch` around the
We noticed this previously where a new draft was able to wipe out portions
of the review request draft (though rarely based on our use case) which
might imply that there was a bug in an older release as you described.
The use case of the extension is that there are automatic status updates
for the code in question which occasionally get written into this custom
extension box on the review request UI. The box is editable so that users
can add additional comments to these automatic status updates.
Unfortunately, these status updates are causing a fair amount of spam
(without the `patch`) as they each require a new draft right now. This
means new emails and review request updates for each possible update which
users don't want.
On Sunday, August 30, 2015 at 2:15:25 PM UTC-7, Christian Hammond wrote:
> Hi Jay,
> Well you definitely don't want to modify Review Board to force that field
> to be accepted in extra_data. That's not a long-term solution. It's also
> very possible that the latest reported issue is yet another side-effect of
> handling the extra_data field incorrectly.
> Fields store extra_data on the review request draft. They're only then
> transferred to the review request when published. If you force content to
> be in ReviewRequest.extra_data while a draft is opened, and then published,
> it's going to be overwritten by the value in ReviewRequestDraft.extra_data,
> which presumably is empty.
> You cannot both use a field *and* force that data into
> ReviewRequest.extra_data. That's not how it's designed, and if it ever
> worked, it was a bug.
> Can you go into the full-on use case of this extension? The entire
> workflow and purpose? That'll help me guide you to the right solution.
> Review Board - https://www.reviewboard.org
> Beanbag, Inc. - https://www.beanbaginc.com
>> Hey Christian,
>> Thanks for getting back to me. We came from 2.0.11. What I noticed what
>> that the field was probably now considered a markdown field which mean't
>> that the review request resource couldn't update it as opposed to any other
>> extra data field.
>> I altered the `update` method of the web API file `review_request.py` to
>> forcefully add the field into the `extra_data` dict.
>> However, the situation I am now running into is that I also have an
>> associated extension button on the page and whenever the extension button
>> is clicked, the `extra_data` for this field is wiped. How can I prevent
>> this from happening? I am under a fair amount of stress to get this
>> operational before the weekend ends so any help would be very appreciated.
>> The field is on the UI and editable by the user to include output notes
>> along with the automated notes.
>> The extension looks something like:
>> class ExtensionOutput(Extension):
>> is_configurable = True
>> def initialize(self):
>> ReviewRequestFieldsHook(self, 'main', [OutputField])
>> ReviewRequestActionHook(self, actions=[
>> 'id': 'button',
>> 'label': 'Special Button',
>> 'url': '',
>> class OutputField(BaseTextAreaField):
>> field_id = 'extension_result_output'
>> label = 'Output'
>> def load_value(self, review_request_details):
>> curr_val = super(OutputField,
>> if not curr_val:
>> return ExtensionOutput.instance.settings['message']
>> except Exception:
>> return "Default message."
>> return curr_val
>> On Saturday, August 29, 2015 at 8:10:45 PM UTC-7, Christian Hammond wrote:
>>> Hi Jay,
>>> What version were you using before you upgraded?
>>> I suspect you're hitting a problem due to a fix we put in several
>>> releases back. It was always the intention that any extra_data key
>>> associated with a custom review request field should be set with the draft
>>> review request API, which would then carry over to the review request when
>>> published, just like any other field.
>>> We had a bug that got fixed where the state between the two was being
>>> shared incorrectly at a specific point, which caused undesired behavior. We
>>> fixed this, and it's possible that exposed a problem in this extension.
>>> How is this field used? Is there a need to expose this field in the UI?
>>> Would you be able to share the source of the field?
>>> On Saturday, August 29, 2015, <jaylee...@gmail.com> wrote:
>>>> Hi All,
>>>> My company has recently upgrade to Review Board 2.0.18.
>>>> We had a number of extensions; one of which was an output box for the
>>>> results of some of our automated machinery.
>>>> The extension was built with a review request fields hook and a
>>>> The `BaseEditableField` had an extra data field on the review request
>>>> with name of `extension_result_output`.
>>>> We used to do PUT requests to the review request resource API to update
>>>> this extra data field. Unfortunately, this no longer works in Review Board
>>>> 2.0.18 with this specific extra data field (I'm guessing this might be due
>>>> to the fact that there is some code interaction with the extension that
>>>> might prevent this).
>>>> A PUT request to the review request resource API can update any other
>>>> extra data field (which we are not using in extensions) except
>>>> Instead, `extension_result_ouptut` can get updated by the review
>>>> request draft resource API, but this causes emails to get sent out on
>>>> 1 line updates to the output box. Additionally, the review request UI will
>>>> get flooded with updates to the box itself. Is there any way to prevent
>>>> this as it currently spams our users both by inbox and through the UI.
>>>> What is causing this discrepancy between why certain extra data fields
>>>> can get updated through the review request resource and others not? We run
>>>> a fairly high traffic Review Board instance. What is a recommended,
>>>> immediate solution and maybe long term solution that we might be able to
>>>> Supercharge your Review Board with Power Pack:
>>>> Want us to host Review Board for you? Check out RBCommons:
>>>> Happy user? Let us know! https://www.reviewboard.org/users/
>>>> You received this message because you are subscribed to the Google
>>>> Groups "reviewboard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to reviewboard+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>> Christian Hammond - chri...@beanbaginc.com
>>> Review Board - https://www.reviewboard.org
>>> Beanbag, Inc. - https://www.beanbaginc.com
>> Supercharge your Review Board with Power Pack:
>> Want us to host Review Board for you? Check out RBCommons:
>> Happy user? Let us know! https://www.reviewboard.org/users/
>> You received this message because you are subscribed to the Google Groups
>> "reviewboard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> For more options, visit https://groups.google.com/d/optout.
Supercharge your Review Board with Power Pack:
Want us to host Review Board for you? Check out RBCommons:
Happy user? Let us know! https://www.reviewboard.org/users/
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.