Re: Issue Updating Review Request Extra Data Fields in 2.0.18
Hi Jay,
How is the field used once there's data in it? Is it simply shown as a
field on the review request page, or is it accessed elsewhere?
I understand the feeling that this is spamming the users, but is the
behavior any different than if you were to edit the description and
publish? I imagine it's the same behavior, which is 100% correct.
If you're looking to have some other form of behavior, and want the
appearance of fields, you need to write a more complicated extension.
Basically, you'd have to introduce new UI that isn't a field in the common
sense, does not get bound at all to a draft, and has its own support for
doing a HTTP PUT to the review request API to set extra_data. This would
therefore not behave like other fields and would not care at all about
drafts. Review Board won't help you a ton here. It'll be necessary to have
your own JavaScript that handles all this.
It's worth noting that Review Board 2.5, which will be out in September,
will allow you to publish drafts without sending e-mail. This is controlled
by the user as an option on the draft banner.
Christian
--
Christian Hammond - christ...@beanbaginc.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com
On Sun, Aug 30, 2015 at 11:46 PM, wrote:
> Hi Christian,
>
> 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
> issue.
>
> 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.
>
> Jay
>
> 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.
>>
>> Christian
>>
>> --
>> Christian Hammond - chri...@beanbaginc.com
>> Review Board - https://www.reviewboard.org
>> Beanbag, Inc. - https://www.beanbaginc.com
>>
>> On Sun, Aug 30, 2015 at 1:05 AM, wrote:
>>
>>> 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):
>>>
>>> cur
Re: Issue Updating Review Request Extra Data Fields in 2.0.18
Hi Christian,
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
issue.
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.
Jay
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.
>
> Christian
>
> --
> Christian Hammond - chri...@beanbaginc.com
> Review Board - https://www.reviewboard.org
> Beanbag, Inc. - https://www.beanbaginc.com
>
> On Sun, Aug 30, 2015 at 1:05 AM, >
> wrote:
>
>> 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,
>> self).load_value(review_request_details)
>> if not curr_val:
>> try:
>> return ExtensionOutput.instance.settings['message']
>> except Exception:
>> return "Default message."
>> else:
>> return curr_val
>>
>> Sincerely,
>> Jay
>>
>> 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?
>>>
>>> Christian
>>>
>>>
>>> On Saturday, August 29, 2015, wrote:
>>>
Hi All,
My company has recently upgrade to Review Board 2.0.18.
>>>
Re: Issue Updating Review Request Extra Data Fields in 2.0.18
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.
Christian
--
Christian Hammond - christ...@beanbaginc.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com
On Sun, Aug 30, 2015 at 1:05 AM, wrote:
> 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,
> self).load_value(review_request_details)
> if not curr_val:
> try:
> return ExtensionOutput.instance.settings['message']
> except Exception:
> return "Default message."
> else:
> return curr_val
>
> Sincerely,
> Jay
>
> 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?
>>
>> Christian
>>
>>
>> On Saturday, August 29, 2015, 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
>>> `BaseEditableField`.
>>>
>>>
>>> https://www.reviewboard.org/docs/manual/2.0/extending/extensions/hooks/review-request-fields-hook/
>>>
>>> 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
>>> `extension_result_output`.
>>>
>>> Instead, `extension_result_ouptut` can get updated by the review request
>>> draft resource API, but this causes emails to get sent out on small 1 line
>>> updates to the output box. Additionally, the
Re: Issue Updating Review Request Extra Data Fields in 2.0.18
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, self).load_value(review_request_details)
if not curr_val:
try:
return ExtensionOutput.instance.settings['message']
except Exception:
return "Default message."
else:
return curr_val
Sincerely,
Jay
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?
>
> Christian
>
>
> On Saturday, August 29, 2015, > 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
>> `BaseEditableField`.
>>
>>
>> https://www.reviewboard.org/docs/manual/2.0/extending/extensions/hooks/review-request-fields-hook/
>>
>> 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
>> `extension_result_output`.
>>
>> Instead, `extension_result_ouptut` can get updated by the review request
>> draft resource API, but this causes emails to get sent out on small 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
>> implement?
>>
>> Thanks,
>> Jay
>>
>>
>> --
>> Supercharge your Review Board with Power Pack:
>> https://www.reviewboard.org/powerpack/
>> Want us to host Review Board for you? Check out RBCommons:
>> https://rbcommons.com/
>> 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
> Be
Re: Issue Updating Review Request Extra Data Fields in 2.0.18
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? Christian On Saturday, August 29, 2015, 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 > `BaseEditableField`. > > > https://www.reviewboard.org/docs/manual/2.0/extending/extensions/hooks/review-request-fields-hook/ > > 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 > `extension_result_output`. > > Instead, `extension_result_ouptut` can get updated by the review request > draft resource API, but this causes emails to get sent out on small 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 implement? > > Thanks, > Jay > > > -- > Supercharge your Review Board with Power Pack: > https://www.reviewboard.org/powerpack/ > Want us to host Review Board for you? Check out RBCommons: > https://rbcommons.com/ > 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 - christ...@beanbaginc.com Review Board - https://www.reviewboard.org Beanbag, Inc. - https://www.beanbaginc.com -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ 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.
Issue Updating Review Request Extra Data Fields in 2.0.18
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 `BaseEditableField`. https://www.reviewboard.org/docs/manual/2.0/extending/extensions/hooks/review-request-fields-hook/ 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 `extension_result_output`. Instead, `extension_result_ouptut` can get updated by the review request draft resource API, but this causes emails to get sent out on small 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 implement? Thanks, Jay -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ 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.
