These tags are preserved by the Closure compiler and vulcanize in order
to serve the license notices embedded in the outputs. In a standalone
Gerrit server, these license are also covered in the LICENSES.txt served
with the documentation. When serving PG assets from a CDN, it's less
obvious what the corresponding LICENSES.txt file is, since the CDN is
not directly linked to a running Gerrit server. Safer to embed the
licenses in the assets themselves.
Change-Id: Id1add1451fad1baa7916882a6bda02c326ccc988
With this change, in merge changes, patch ranges can diff against a
specific parent (as indicated by a negative parent index) similarly to
the GWT UI.
- Parent options appear in patch range selectors when available.
- The router no longer redirects parent indexed patch ranges now that
they are supported.
- The RevisionInfo class is added to house revision related functions in
a form that's easily passed between components.
- On merge changes the default patch range base is labeled as
"AutoMerge" rather than "Base".
Feature: Issue 4760
Change-Id: I221ba97e28be52f225f7d90f5f8c5a0f17ddb8c2
Observing both revisions and _sortedRevisions in <gr-patch-range-select>
is unnecessary.
This change does not fix any bugs, but does simplify the code.
Change-Id: I01e5562e3ca40ba5f0be1d73036bbeb70313c7cf
As discussed with UX (and as exists in GWTUI), highest-first order is a
more convenient ordering for patchset dropdowns.
Bug: Issue 7551
Change-Id: I6212d293accbee3772c2765f1e20e951f110d4d2
Previously, comments were not used as a parameter in the computed
function that calculated patch range values. Instead, it just used the
value of 'comments' when the patch dropdown was computed.
However, if comments were loaded after the dropdown values were
calculated, it was not updated to display the comment counts.
This change fixes the problem by using comments as a parameter in the
value calculations, and includes a default empty object in the case that
comments are not used as an input for the patch range selector
(currently the diff view).
Bug: Issue 7444
Change-Id: I2646800afc1632bf39b3c6a451c848669007ca18
Two-way databinding was causing some cyclical UI updating, resulting in
an incorrect redirect URL. Instead of binding to the patchNum and
basePatchNum in both directions, the patch-range-select fires an event
when it notices a change in the selected patchsets.
Bug: Issue 7336, Issue 7315, Issue 7316
Change-Id: Ifdf476dcf4fa1353d0b280d7e6dd25e4ef40865a
This also moves the change reloading logic back to the change view,
where it gets updated patch ranges via a two-way data binding.
Change-Id: Ib09ad1a176ba96bac77a513d344226df029aef7b
Slight refactoring required in order to satisfy both use cases:
- Fire an event when patch range changes and let parent element
handle it.
- Support comment strings
- availablePatches becomes an array of objects instead of an
array of integers.
Change-Id: Ia8da9296f41eb2d45c9358d03fbec3940273ad9d
ORIGINALLY: Iafd4b80af53624027c347f0f443b4cdfde292e29
This change makes the change view and the diff view change edit aware.
Mutation operations on edit itself, like editing files in editor, are
beyond the scope of this change.
Change edits must be fetched with a separate change edit endpoint and
merged into the change.revisions object. The _number of an editInfo is
'edit'. It has a special property called 'basePatchNum' that marks
which patch set the edit is based on. In patch set selectors, the edit
is sorted right after its basePatchNum.
Alternative implementation considerations:
It could be easier to handle edits on the Polygerrit UI, if
GET /changes/<id>/detail endpoint
would optionally include the change edit in the resulting
change.revsions map.
TODOs:
* Overwrite change.current_revision with change edit commit in some
use cases
* Mark the change edit as Change Edit in the header of the change view
* Allow for modification of the edit in the change/diff view
* Disable commenting on files in edit patchsets
* Modify file list rows to have appropriate actions when edit is
selected (e.g. allow revert, disable marking as reviewed)
* Identify and whitelist valid change/revision actions for an edit
Bug: Issue 4437
Change-Id: Ia4690d20954de730cd625ac76920e849beb12f7c
Some browsers crash when allowed to have extremely long options in a
dropdown. This change truncates the user-supplied field of patch set
descriptions to 500 chars to prevent these crashes.
Bug: Issue 5085
Change-Id: I1fa5df3badb4ceca90519dfcd89369376992c432
Adds an editable label allowing the change owner to edit patchset
descriptions within the UI.
Also re-styles the dropdowns pertaining to patchsets for better UX.
Feature: Issue 4544
Change-Id: I15c0f8ab6a60c3a06482fe152539615d31eeae0f
This change adds the patch set description, if it exists, in every patch
set select in the change view and the diff view. Also includes
refactoring of an existing function into a behavior for use in other
files, and removes some unnecessary DOM nodes from the change-view.
http://imgur.com/a/rEhOF
Feature: Issue 4544
Change-Id: Id5f8d2d5750f3f7afc677e16c411327f53487b19
Previously, on a changelist or file view, if you change the patchset
to a lower number and then click the back button, dropdown value did not
change properly. The issue was related to how the selected option was
rendered in a dom-if. This change refactors the gr-select element to fit this
use case.
Bug: Issue 4800
Change-Id: I66ee5b7aba5421a01ca79f9e72a853a73c32e589
There is no change in functionality. Only moving things around.
+ Separate html from the js.
+ Place the unit test for a component within the same folder.
+ Organize the components in subfolders.
Change-Id: I51fdc510db75fc1b33f040ca63decbbdfd4d5513
