Ah interesting, Most people do put the summary/description into the changeset and post from there, populating the review request with that information.
I haven't seen any workflows for syncing that back up. That's generally not a hard requirement that I've seen at companies. Some companies want the content to match in both places, but others don't, so we don't enforce anything there. If you are wanting to keep those in sync, I think that your rbt-submit script idea is maybe your best bet, unless you can do something with P4 triggers to either enforce or sync up state. A pattern we have seen is using triggers to enforce that a change is reviewed by looking for a line in the change description showing the review request URL. The trigger can then check the API result for that review request and see if "approved" is set. That way, regardless of the commit message, you have the review request's version of the information associated (just not embedded), and you have P4-side validation of approved changes. Christian On Wed, Jul 20, 2022 at 2:35 PM Matt Blythe <[email protected]> wrote: > Hi Christian, > > Thanks for the quick reply! > > > Is it possible to instead go the other way, have Review Board sync any > changes to the other location on publish? > > Not exactly. The other location can only be modified by the owner, so in > order for a WebHook or extension to work, it would need authentication > credentials for the owner, which is a can of worms I don't want to get into. > > Maybe it's better to put things in concrete terms... > > My organization (unfortunately) uses perforce as our SCM. I've written > some convenience scripts for my team to create and update review requests - > "rbt-new" and "rbt-update". Both of these scripts take the user's intended > commit message, put it into a P4 numbered changelist (along with the local > changes for review), then call "rbt post --guess-fields <changelist > number>" so that the review's Summary & Description fields match the > intended commit message. > > So, in my case, this P4 numbered changelist is the "other location" where > the Summary and Description fields are stored. And P4 only lets the owner > of the changelist make updates. I've coached my team to only use > rbt-update when changing the Summary/Description to keep things in sync, > but, well, humans will be human. > > I think I can work around it another way, though... I also have a > "rbt-submit" convenience script that mostly looks up the existing numbered > changelist, then call "p4 submit" with it. I can have that script hit the > API to get the current field values and update the P4 change (if necessary) > before it's submitted. IMO, it's a bit ugly to do that, but probably less > ugly than hacking up an extension to disable web editing. > > Alternatively, is there a different recommended P4/rbt workflow that > avoids this issue? > > Thanks, > MattB > > On Wed, Jul 20, 2022 at 2:04 PM Christian Hammond < > [email protected]> wrote: > >> Hi Matt, >> >> It can probably be done via an extension, though Review Board isn't >> explicitly designed for this and we don't have any official mechanism for >> this. So it may change in the future. >> >> Is it possible to instead go the other way, have Review Board sync any >> changes to the other location on publish? This could be done via WebHooks >> or extensions. >> >> If you want to disable editing of fields entirely, you'd probably need to >> change 'is_editable' to 'False' on all registered fields, doing something >> like: >> >> >> from reviewboard.reviews.fields import fields_registry >> >> for field_cls in fields_registry: >> field_cls.is_editable = False >> >> >> Or selectively fetch the fields you want to disable >> (fields_registry.get('<field_id>')) and set them there. >> >> Christian >> >> On Wed, Jul 20, 2022 at 12:13 PM Matt Blythe <[email protected]> >> wrote: >> >>> Hi, >>> >>> In my organization, I have some tooling built around 'rbt' so that when >>> my users create and update review requests, it also stores some of the data >>> off in a separate location. When users change the review request through >>> the web frontend, this data gets out of sync. >>> >>> Is there a way to disable editing fields of the review request through >>> the web gui, but still allowing changes to be made via 'rbt post' or the >>> APIs? If not, could it be done through an extension? >>> >>> Thanks, >>> MattB >>> >>> -- >>> 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 "Review Board Community" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/reviewboard/a65e9ae6-d825-4f93-bde6-8ab940ca7d30n%40googlegroups.com >>> <https://groups.google.com/d/msgid/reviewboard/a65e9ae6-d825-4f93-bde6-8ab940ca7d30n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Christian Hammond >> President/CEO of Beanbag <https://www.beanbaginc.com/> >> Makers of Review Board <https://www.reviewboard.org/> >> >> -- >> 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 a topic in the >> Google Groups "Review Board Community" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/reviewboard/OFNDnwfWZuM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/reviewboard/CAE7VndmzGbRoED4KwQ6M-rWXn7YxCFU96DXpzCT2HAk79v_RzA%40mail.gmail.com >> <https://groups.google.com/d/msgid/reviewboard/CAE7VndmzGbRoED4KwQ6M-rWXn7YxCFU96DXpzCT2HAk79v_RzA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 > "Review Board Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/reviewboard/CAL6bcug883NanA2SktinCb24yg980aNY31-K4BzAi37yA5fC5w%40mail.gmail.com > <https://groups.google.com/d/msgid/reviewboard/CAL6bcug883NanA2SktinCb24yg980aNY31-K4BzAi37yA5fC5w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Christian Hammond President/CEO of Beanbag <https://www.beanbaginc.com/> Makers of Review Board <https://www.reviewboard.org/> -- 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 "Review Board Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/CAE7Vndk8BsUZ_W0A7a3runF8cOPUpLUNwo1Zu_kE06z3HpzguA%40mail.gmail.com.
