Stephen Finucane [Wed, 11 May 2022 09:30:45 +0000 (10:30 +0100)]
parser: Handle binary git patches
'git-format-patch' is able to generate binary patches. Fortunately,
these are quite easy to spot since they're explicitly labelled as such.
Add support for parsing these to the parser.
Stephen Finucane [Wed, 11 May 2022 09:08:10 +0000 (10:08 +0100)]
[StableOnly] Fix docs job
This is a combination of multiple commits from master:
60a7b11d docs: pin mistune version due to breakage 7544f8f5 requirements: Bump doc requirements 0968130a Revert "docs: prevent build error by rolling back Sphinx version" 65547c87 docs: prevent build error by rolling back Sphinx version bdb049c7 requirements: Update doc requirements
Though we don't usually change requirements on stable branches, this one
seems okay since it only affects docs builds and not production code.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Ali Alnubani [Sun, 24 Apr 2022 20:59:35 +0000 (23:59 +0300)]
lib: fix table names
Migration 0042 (introduced in 0686a73) renamed the "Comment" model
to "PatchComment", and some of the table names changed in a51e7cf
were already correct.
This reverts a51e7cf and removes a nonexistent table name to resolve
the following error:
$ psql -f lib/sql/grant-all.postgres.sql DATABASE_NAME
BEGIN
psql:lib/sql/grant-all.postgres.sql:38: ERROR: relation
"patchwork_comment" does not exist
Fixes: a51e7cfd95e2 ("lib: Correct PatchComment table") Fixes: 7b967db4e12f ("lib: Update DB permissions to reflect model changes") Cc: stephen@that.guru Closes: #396 Signed-off-by: Ali Alnubani <alialnu@nvidia.com>
(cherry picked from commit 5b53f46def5fc4961bfa77a8abb3e968ae839c59)
Stephen Finucane [Fri, 19 Nov 2021 12:09:06 +0000 (12:09 +0000)]
Switch from Travis CI to GitHub Actions
Travis has imposed quotas on builds that require us to contact them to
obtain OSS credits. The CI tool is irrelevant so long as builds do
happen, so switch to GitHub Actions for now. This is a little more
complicated that the switch for related projects like git-pw, given the
need for a database service. We may wish to investigate reusing some of
our own Docker files in the future but for now, this should do the
trick.
Daniel Axtens [Thu, 19 Aug 2021 03:04:26 +0000 (13:04 +1000)]
migrations: ignore flake8 on 0041_python3
commit 3a979ed8bfc6 ("migrations: don't go to the db for 0041_python3 migration")
made a bunch of strings go past 79 characters, breaking flake8 checks.
`black` doesn't seem to fix this and reflowing the strings manually is
error-prone.
We're not really expecting future changes to this file so just don't run
flake8 against it.
Fixes: 3a979ed8bfc6 ("migrations: don't go to the db for 0041_python3 migration") Signed-off-by: Daniel Axtens <dja@axtens.net>
(cherry picked from commit 77793ad6ebc8469a7af9b3be05b4f7e21c389b57)
Stephen Finucane [Thu, 28 Oct 2021 10:38:41 +0000 (11:38 +0100)]
requirements: Pin jsonschema
The new 4.x release of jsonschema has borked our schemas for reasons I
do not yet fully understand (though I have an idea - see inline). Unbork
things now and fix our CI, while we work on a longer-term fix.
Conflicts:
requirements-test.txt
Changes:
requirements-text.txt
NOTE(stephenfin): The conflict is because we're using a slightly older
version of openapi-core here which we don't want to update. We also need
to modify the file futher to pin openapi-schema-validator to keep pip
happy since openapi-schema-validator 0.2.0 requires jsonschema > 4.0.
Signed-off-by: Stephen Finucane <stephen@that.guru>
We recently started stripping comments and folding white space from the
In-Reply-To and References headers. Do so also for the Message-ID
header. Because of the importance of the Message-ID header, we accept
even non-compliant headers and because we now have a pattern for this,
we also start (re-)accepting non-compliant In-Reply-To headers.
Conflicts:
patchwork/parser.py
NOTE(stephenfin): Conflicts are due to the absence of commit 94d75a1c78
("Blackify code") which we don't want to backport.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Related: #399
parser: Ignore CFWS in In-Reply-To, References headers
RFC2822 states that [1] a comment or folding white space is permitted to
be inserted before or after a msg-id in in the Message-ID, In-Reply-To
or References fields. Allow for this.
NOTE(stephenfin): Conflicts are due to the absence of commits f5cd52144c
("parser: Add 'X-Patchwork-Action-Required' header") and 94d75a1c78
("Blackify code"), neither of which we want to backport.
Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: DJ Delorie <dj@redhat.com> Closes: #399
Daniel Axtens [Fri, 20 Aug 2021 14:57:58 +0000 (00:57 +1000)]
REST: Don't error if a versioned field we would remove is absent
We remove fields that shouldn't be seen on old versions of the API.
This was done with `pop(field name)`, which will throw an exception
if the named field is absent from the data. However, sometimes if
a patch request is via an old API version, we hit this line without
ever having the field present.
This is odd, but not harmful and we definitely shouldn't 500.
Signed-off-by: Daniel Axtens <dja@axtens.net>
[stephenfin: Merge test into bug fix] Signed-off-by: Stephen Finucane <stephen@that.guru> Tested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Fixes: d944f17ec059 ("REST: Use versioning for modified responses") Closes: #423
(cherry picked from commit 5c22f9d8fcc72deec7d8beaefc97207ea8fc646d)
Daniel Axtens [Fri, 16 Jul 2021 17:19:37 +0000 (03:19 +1000)]
migrations: don't go to the db for 0041_python3 migration
When we moved to Python 3, makemigrations wanted to change a bunch of
things, see commit 4ad87ed72aec ("migrations: Add the Python 3 patch").
The change is, as observed then, just to make django happy; it's not
supposed to change the database at all.
So make the migration change the state as seen by Django only.
This makes the migration ~instant, even for a huge database.
Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Stephen Finucane <stephen@that.guru>
Related: #420
(cherry picked from commit 3a979ed8bfc69aecb38e3a8280e87996c5384482)
Commit e5c641fc4 optimized fetching of checks when displaying a patch by
prefetching these checks ahead of time. Unfortunately we missed that
this should exclude older versions of checks for a given context. Make
the code used to generate the unique checks generic and allow us to use
that as a filter to the checks provided to the template, restoring the
correct behavior.
Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #398 Fixes: e5c641fc4 ("Optimise fetching checks when displaying a patch")
(cherry picked from commit a43d6acda0939c14e8135549968815876680d497)
Stephen Finucane [Wed, 24 Feb 2021 15:26:08 +0000 (15:26 +0000)]
lib: Correct PatchComment table
The table is 'patchwork_comment', not 'patchwork_patchcomment'. Correct
this.
Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #396 Fixes: 7b967db4 ("lib: Update DB permissions to reflect model changes")
(cherry picked from commit a51e7cfd95e24d6757a146e9c8e8f3aec44b226c)
Stephen Finucane [Wed, 24 Feb 2021 15:08:45 +0000 (15:08 +0000)]
api: do not fetch every patch in a patch detail view 404 (v2)
Commit 08c5856 fixed an issue whereby a 404 on the aforementioned URL
could result in a large DB query due to DRF attempting to populate the
'related' list box with all patches on the instance. That was
accidentally reverted in commit fe07f30. "Unrevert" this change.
Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: fe07f30 ("Remove 'PatchRelationSerializer'") Closes: #397
(cherry picked from commit 79700f321335a2d7c649eb03932797af521942a0)
Stephen Finucane [Sat, 20 Feb 2021 14:35:07 +0000 (14:35 +0000)]
models: Use parent model to get comment's 'list_archive_url'
We were attempting to retrieve the 'list_archive_url' attribute from the
'PatchComment' or 'CoverComment' instances, rather than the parent
'Patch' and 'Cover' object, respectively. Correct this and add plenty of
tests to prevent this regressing.
Stephen Finucane [Sat, 20 Feb 2021 13:27:08 +0000 (13:27 +0000)]
tests: Fix compatibility with openapi_core 0.13.7
It seems the 'openapi_core.schema.schemas.models.Format' mechanism of
defining custom formatters was deprecated in openapi_core 0.12.0 but we
never noticed. They've finally broken it in 0.13.7. Switch to the new
thing, 'openapi_core.unmarshalling.schemas.formatters.Formatter', which
expects a slightly different format.
Stephen Finucane [Sat, 20 Feb 2021 12:22:08 +0000 (12:22 +0000)]
urls: Support sha256-based tokens
Django 3.1 changed the default hashing algorithm used for things like
password reset tokens from SHA-1 to SHA-256. As noted in the release
notes [1], this is configurable via the 'DEFAULT_HASHING_ALGORITHM'
transitional setting, but that's only intended to allow upgrades of
multiple instances in a HA deployment and shouldn't be used post
upgrade. Instead, we need to fix our URLs to support the longer tokens
generated by SHA-256.
Long term, we want to replace these regex-based routes with the simpler
flask-style template string routes. That's not really backportable so
we'll do that separately.
Stephen Finucane [Sun, 13 Dec 2020 19:44:53 +0000 (19:44 +0000)]
requirements: Switch to openapi-core 0.13.4
In commit b7f3c3d34 ("tests: Switch to openapi-core 0.13.x") we added
support for 'openapi-core' 0.13.x. However, we needed to use a commit
from master since an important fix [1] was not included in the latest
release at the time, 0.13.3. 0.13.4 has since been released so let's
move on and use that.
Stephen Finucane [Sun, 29 Nov 2020 12:50:22 +0000 (12:50 +0000)]
REST: Null out previous, current relation info
These fields don't work like we expect them to. Because we're linking to
a non-idempotent entity, an instance of 'relation', what we're storing
in either of these fields is subject to change as patches are added and
removed. This makes the information pretty much useless after the fact.
It's best to just state the patch and request that people query the
information themselves if necessary. We don't want to remove the field
entirely from the API - that would be a truly breaking change - so
instead we null it out like we do for patch tags. In a v2 API (i.e. a
major version bump) we can remove this entirely.
A small bug with the schema generation is corrected.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Related: #379
This wasn't writeable for reasons I haven't been able to figure out.
However, it's not actually needed: the 'PatchSerializer' can do the job
just fine, given enough information. This exposes a bug in DRF, which
has been reported upstream [1]. While we wait for that fix, or some
variant of it, to be merged, we must monkey patch the library.
tests: Add tests for 'patch-relation-changed' events
This event is rather odd. If you have two patches then the way a
relation is created is by creating a 'PatchRelation' instance and then
setting the 'related' attribute on the first patch followed by the
second patch. Because the event uses the 'Patch' model's 'pre_save'
signal, we'll only see events for the patch being currently saved. This
means no event will be raised for the first patch and only one event,
the one for the second patch, will be raised when the second patch is
being added to the relationship.
In hindsight, the structure of the event is off. We should have had
something like a 'patch-added-to-relationship' and a
'patch-removed-from-relationship' event, both with the same fields:
'project', 'actor', 'patch' and 'related', the latter of which would
have listed all of the _other_ patches in the relationship. Sadly, this
is an API change which means we can't do it now. We may well wish to do
so in the future though.
Signed-off-by: Stephen Finucane <stephen@that.guru>
This wasn't actually creating just a patch relation object - it was also
creating patches, which is something we already have an explicit helper
for. Clean this thing up.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Sat, 28 Nov 2020 17:32:32 +0000 (17:32 +0000)]
lib: Grant SELECT on auth_user
If a mail arrives with the 'X-Patchwork-Delegate' hint header, the
'patchwork.parser' script will need to index the users table to find the
appropriate user. This should be okay from a security perspective since
passwords are hashed and salted and the rest of the information is
mostly accessible publicly via the web UI and REST API.
Signed-off-by: Stephen Finucane <stephen@that.guru> Suggested-by: Ali Alnubani <alialnu@mellanox.com> Closes: #365
The patch_mbox view returns text/plain data without specifying a character
set, which means clients will assume the default of iso-8559-1 as defined
in the HTTP/1.1 standard. Since the data being returned is in fact utf-8
encoded, set the encoding accordingly in the HTTP Content-Type header.
Reported-by: Jakub Kicinski <kuba@kernel.org> Suggested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Stephen Finucane [Sat, 28 Nov 2020 16:34:01 +0000 (16:34 +0000)]
parser: Update reference to PatchComment
Commit 0686a736fbf6d869bd31bd135ba38080ac96de22 split out 'CoverLetter'
from the old 'Submission' model, removing the common 'Comment' model in
favour of distinct 'CoverComment' and 'PatchComment' models in the
process. Unfortunately we misssed some references to the old model in
the 'patchwork.parser' module. Correct these now, adding unit tests to
prevent regressions.
Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: 0686a736 ("models: Split 'CoverLetter' from 'Submission'") Closes: #384
models: Validate Project.linkname does not contain forward slash
I started by creating a project that contained a forward slash
(importing patches from https://lists.sr.ht/~sircmpwn/sr.ht-dev/) and
it fails to render the "projects" main page.
The specific error reads:
NoReverseMatch at /
Reverse for 'patch-list' with keyword arguments
'{'project_id': 'foo/bar'}' not found. 1 pattern(s) tried:
['project/(?P<project_id>[^/]+)/list/$']
which appears to explicitly disallow forward slashes.
So I think it makes sense to validate that project linkname doesn't
contain forward slahes.
This implementation uses the validate_unicode_slug validator instead of just
rejecting inputs that contain forward slashes.
Signed-off-by: Thomas Bracht Laumann Jespersen <t@laumann.xyz> Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #380
Django 3.1 adds a new admin sidebar feature that requires the
django.template.context_processors.request context processor to be enabled
in the settings.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Stephen Finucane <stephen@that.guru>
Andrew Donnellan [Thu, 27 Aug 2020 14:14:03 +0000 (00:14 +1000)]
urls: Update url pattern functions
Django 3.1 deprecates django.conf.urls.url() as an alias for
django.urls.re_path(). Also switch to using django.urls.include() rather
than django.conf.urls.include().
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Stephen Finucane <stephen@that.guru>
Rohit Sarkar [Sat, 1 Aug 2020 06:24:15 +0000 (11:54 +0530)]
management: introduce replacerelations command
The replacerelations script is used to ingest relations into Patchwork's
patch database. A patch groups file is taken as input, which on each
line contains a space separated list of patchwork ids denoting a
relation. All the existing relations in Patchwork's database are removed
and the relations read from the patch groups file are ingested.
Signed-off-by: Rohit Sarkar <rohitsarkar5398@gmail.com>
[dja: pep8, drop relations directory as empty dirs don't get stored by git,
comment about how lines are generated.] Signed-off-by: Daniel Axtens <dja@axtens.net>
Stephen Finucane [Thu, 30 Apr 2020 21:22:10 +0000 (22:22 +0100)]
tox: Add default Django version
I occasionally forget myself and run e.g. 'tox -e pyNN' when I want to
sanity check something instead of 'tox -e pyNN-djangoMM'. Add fallback
Django versions so that this doesn't crash and burn. It's less succict
than it could be since tox doesn't seem to support '!django{22,30}'
(yet!).
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Sun, 26 Apr 2020 13:17:57 +0000 (14:17 +0100)]
migrations: Resolve issues with other DB backends for 0042, 0043
0042 was using MySQL-specific SQL to delete entries in the
'patchwork_comment' table that were associated with entries in the
'patchwork_coverletter' table, while 0043 only considered MySQL and
PostgrSQL when attempting to copy fields from 'patchwork_patch' to
'patchwork_submission'. Both issues are resolved.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Fri, 10 Apr 2020 11:08:32 +0000 (12:08 +0100)]
migrations: Squash 0001 to 0040
Now that we're moving a new major version, we can squash the migrations
we have to date. This coexists alongside the old migrations, which we
can remove and replace entirely when we release 4.0, per the advice of
the 'squashmigrations' tool.
You should commit this migration but leave the old ones in place; the
new migration will be used for new installs. Once you are sure all
instances of the codebase have applied the migrations you squashed,
you can delete them.
The 'squashmigrations' tool can't parse the output of 'RunPython' blocks
so the output of the tool was less optimized than it could be. As a
result, we've manually modified this change to remove the 'RunPython'
block and unnecessary 'AlterField' entries. This was done by removing
all migrations and generating a new "initial" migration, which was then
modified to mark all strings as byte strings (as they were when we were
using Python 2 to generate these migrations) so that 0041 would apply
cleanly.
The main benefit of this change is that it significantly reduces the
startup time for unit tests. Executed on my host, the run time for a
single test goes from ~ 22 seconds to ~ 14 seconds. This is obviously
reduced for additional tests.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Oh, the follies of youth. Time to undo the damage of 2.0.0, specifically
commit 86172ccc16, which split Patch into two separate models using
concrete inheritance. As noted previously, this introduced a large
number of unavoidable JOINs across large tables and the performance
impacts these introduce are blocking other features we want, such as
improved tagging functionality. To combine these two models, we must do
the following:
- Update any references to the 'Patch' model to point to the
'Submission' model instead
- Move everything from 'Patch' to 'Submission', including both fields
and options
- Delete the 'Patch' model
- Rename the 'Submission' model to 'Patch'
With this change, our model "hierarchy" goes from:
Submission
Patch
PatchComment
Cover
CoverComment
To a nice, flat:
Patch
PatchComment
Cover
CoverComment
I expect this migration to be intensive, particularly for MySQL users
who will see their entire tables rewritten. Unfortunately I don't see
any way to resolve this in an easier manner.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Sat, 29 Feb 2020 17:20:50 +0000 (17:20 +0000)]
models: Split 'CoverLetter' from 'Submission'
We want to get rid of the split between 'Patch' and 'Submission' because
of the cost of using JOINs basically everywhere we use 'Patch'. Before
we do that, we need to move the other users of 'Submission' to other
models and other models that rely on these users sharing the common
'Submission' base. For the former, there is only one user,
'CoverLetter', while for the latter there is only the 'Comment' model.
As a result, we must do the following:
- Create a new 'Cover' model
- Create a new 'CoverComment' model
- Move everything from 'CoverLetter' to 'Cover' and all entries
associated with a 'CoverLetter' from 'Comment' to 'CoverComment'
- Delete the 'CoverLetter' model
- Rename the 'Comment' model to 'PatchComment'
This means our model "hierarchy" goes from:
Submission
Patch
CoverLetter
Comment
To:
Submission
Patch
PatchComment
Cover
CoverComment
A future change will flatten the 'Submission' and 'Patch' model.
Note that this actually highlighted a bug in Django, which has since
been reported upstream [1]. As noted there, the issue stems from MySQL's
refusal to remove an index from a foreign key when DB constraints are
used and the workaround is to remove the foreign key constraint before
altering the indexes and then re-add the constraint after.
[1] https://code.djangoproject.com/ticket/31335
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Sat, 18 Apr 2020 12:21:13 +0000 (13:21 +0100)]
travis: Resolve warnings, info messages from Travis
The following were reported by Travis' build config validation:
- root: deprecated key 'sudo' (The key `sudo` has no effect anymore.)
- env: key 'matrix' is an alias for 'jobs', using 'jobs'
- root: key 'matrix' is an alias for 'jobs', using 'jobs'
- root: missing 'os', using the default 'linux'
Resolve all of the above.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Jeremy Kerr [Thu, 16 Apr 2020 01:29:25 +0000 (09:29 +0800)]
tests: ensure we don't see database errors during duplicate insert
Currently, the parser causes IntegrityErrors while inserting duplicate
patches; these tend to pollute database logs.
This change adds a check, which currently fails, to ensure we do not
cause errors during a duplicate patch parse.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Stephen Finucane <stephen@that.guru>
[stephenfin: Add 'expectedFailure' marker to keep all tests green]
Andrew Donnellan [Wed, 15 Apr 2020 09:06:56 +0000 (19:06 +1000)]
parser: Don't crash when From: is list email but has weird mangle format
get_original_sender() tries to demangle DMARC-mangled From headers, in
the case where the email's From address is the list address. It knows how
to handle Google Groups and Mailman style mangling, where the original
submitter's name will be turned into e.g. "Andrew Donnellan via
linuxppc-dev".
If an email has the From header set to the list address but has a name that
doesn't include " via ", we'll throw an exception because stripped_name
hasn't been set. Sometimes this is because the list name is seemingly
empty, resulting in a mangled name like "Andrew Donnellan via"
without the space after "via" that we detect. Handle this as well as we can
instead, and add a test.
Fixes: 8279a84238c10 ("parser: Unmangle From: headers that have been mangled for DMARC purposes") Reported-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Wed, 15 Apr 2020 15:52:08 +0000 (16:52 +0100)]
tests: Switch to openapi-core 0.13.x
We've done the necessary work here already so this is a relatively easy
switchover. However, we do have to work around an issue whereby the
first possible matching route is used rather than the best one [1]. In
addition, we have to install from master since there are fixes missing
from the latest release, 0.13.3. Hopefully both issues will be resolved
in a future release.
Stephen Finucane [Wed, 15 Apr 2020 15:44:32 +0000 (16:44 +0100)]
tests: Drop Django 1.x support
openapi-core 0.13.x has added support for Django validation. Before we
migrate to that version and presumably remove most of this code, remove
the stuff that is *definitely* dead.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Thu, 16 Apr 2020 13:03:54 +0000 (14:03 +0100)]
docs: Resolve issues with 'relations'
Two issues here:
- 'PATCH /patches/{id}' and 'PUT /patches/{id}' expect a list of
integers on the 'related' field - not strings
- 'GET /patches' and 'GET /patches/{id}' return a list of embedded patch
objects on the 'related' field - not strings
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Thu, 16 Apr 2020 12:45:28 +0000 (13:45 +0100)]
docs: Resolve issues with 'events'
Four things to change here:
- The response is any array that can contain any type of event, not one
of them.
- The 'actor' field is nullable.
- The 'cover' field of the 'cover-created' event is an embedded cover
letter, not a string.
- The specifications for the 'current_delegate' and 'previous_delegate'
fields of the 'patch-delegated' field were apparently invalid.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Wed, 15 Apr 2020 23:51:17 +0000 (00:51 +0100)]
docs: Resolve issues with 'covers'
Two issues to correct:
- Each header in the 'headers' field can be either a string or a list
value.
- We state that the 'content' field will always have content but our
tests were configuring otherwise.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Wed, 15 Apr 2020 22:36:59 +0000 (23:36 +0100)]
docs: Resolve issues with 'patches'
Four issues to resolve:
- The 'tags' field is a key-value mapping, not an array.
- Each header in the 'headers' field can be either a string or a list
value.
- Errors are reported as a mapping of the field name to an array of
errors, not a string.
- The security type information isn't complete and doesn't account for
security types. Skip it for now.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Stephen Finucane [Wed, 15 Apr 2020 22:37:17 +0000 (23:37 +0100)]
docs: Make embedded fields nullable by default
As discussed at [1], "subtypes can add restrictions, but they cannot
relax restrictions that are already in place." These fields need to be
marked nullable and then "subclassed" to set non-nullability if
required.
projects / thirdparty / patchwork.git / log
