[How should review request be separated?]:
How should review request be separated?
Before that, your latest diff has some stuff in there that doesn’t belong to your change.
it looks like your branch might be out of sync with master, so you need to do is pull in the changes from your reviewboard master, and merge them in.
This means fetching and pulling the changesets on the master branch, merging them in (and doing conflict resolution if needs be), and then pushing the merge back to your branch.
I think those things should be 1 review request
And then there are little atomic additions to these core components like displaying the trophy’s in the user page, for example.
Removing that addition does not break the core components, so that’s what I generally use as a litmus test to determine how to break something up.
especially when working on something with someone else.
[found a bug]:
basically, make a review request, submit it, then go to the drop down you showed me that says submit, so the drop down that’s close -> submit
you’ll see it say “this change has been marked as submitted”
but if you click the “describe the submission…” text area and add anything, it’ll auto-discard
auto-discard? does it happen on the master branch?
weird, i did it on master before i posted my status report, and it did it. now it doesn’t
I fill out that field all the time, so I was surprised to hear it broke
lll take another look again next time I’ve got it open to see what’s the difference between mine and master lol
[the way you’re saving fields]:
it also looks here like you’re concerned that the way we’re saving fields is fragile? or, limiting
right now, as per line 708 in reviews/views
if latest_changedesc and ‘status’ in latest_changedesc.fields_changed:
status = latest_changedesc.fields_changed[‘status’][‘new’]
if status in (ReviewRequest.DISCARDED, ReviewRequest.SUBMITTED):
close_description = latest_changedesc.text
basically, i have no way of grabbing multiple text fields/boxes upon update, as far as I’m aware. Can you think of a way to deal with this?
I would expect they’d be handled just like the close description
if status == SUBMITTED, pull out the other two fields
if the submit banner is showing, they’d be used to populate those entries
the way it works is that, whenever the submit banner’s fields (well, field) is updated, we update the laetst change description (if it’s a status change), or we create a new one
so I think what you’d want is, for each of the two new fields, we repeat that whole block, but tailor it to the field in question
(no, it’s not pretty, but it’s the only place to do it)
[how do i get those two fields info?]:
what i don’t understand is how do i get those two fields info as “latest_changedesc.text” will only have the one most recently changed
they wouldn’t go in there
so take a look at ChangeDescription in changedescs/models.py
text is one of the fields, but you also have a fields_changed
this is where the record of those fields would go
any time one of those fields is changed, the last change description shoud be updated with them (we do that for the ‘status’ today)
instead of pulling out latest_changedesc.text, we’d pull out, say, latest_changedesc.fields_changed[‘revision’][‘new’]