| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
component description pages
|
|
disallow duplicate nicks
|
|
|
|
|
|
|
|
|
|
|
|
contain U+FFFF
|
|
some default configuration
|
|
setting exact list
|
|
|
|
|
|
row format, and changes charset to utf8mb4)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
syncing is currently broken on prod bmo
|
|
|
|
|
|
linked BMO account accepts BMO linked revision
|
|
if the bug is private, otherwise leave it alone
|
|
|
|
|
|
|
|
|
|
|
|
|
|
standard options; mark PDF viewable
|
|
|
|
or /bug/ALIAS."
This reverts commit 404dc5496967203c5f99755340f43d712420446a.
|
|
unread changes/comments
|
|
current BMO infrastructure.
|
|
|
|
scroll
|
|
|
|
class method DYNAMIC_COLUMNS
When working on bug 1253535 I kept encountering the fragility of our model system.
This fragility involves two things:
1) Extensions adding new columns to model objects
2) The use of those model objects in checksetup.
In particular, the SecureMail extension causes this problem because (at checksetup-time) we need to lookup certain Group objects.
Thus I propose to
1) allow model classes to take their list of columns from the informations schema (exposed via `bz_table_columns_real`)
2) Have Bugzilla::Group do this when being used in a commandline (e.g. checksetup) context.
|
|
the revision with the project
|
|
author
|
|
instead of PhabricatorProjectsPolicyRule
|
|
|
|
|
|
|
