Disable edits from the web gui?

[Matt Blythe]

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

[Christian Hammond]

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

--
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 reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/a65e9ae6-d825-4f93-bde6-8ab940ca7d30n%40googlegroups.com.

--

Christian Hammond

President/CEO of Beanbag

Makers of Review Board

[Matt Blythe]

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

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 reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/CAE7VndmzGbRoED4KwQ6M-rWXn7YxCFU96DXpzCT2HAk79v_RzA%40mail.gmail.com.

[Christian Hammond]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/CAL6bcug883NanA2SktinCb24yg980aNY31-K4BzAi37yA5fC5w%40mail.gmail.com.