Cfapp integration #1
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Thanks to Jelte for most of this. I basically just moved the SQL code to a migration and stood up a dev environment via make. The downgrading of parentid to null-able was required though I do not know why. I added a couple of views to make interactive "select *" doable. Added an upsert to ensure that a dev setup has a list. I reworked the text search configurations from what was in schema.sql. I couldn't figure out how to make the existing code work and for my development needs it wasn't important.
Note: None of this is fully fleshed out. Mainly because it isn't
my primary focus at the moment; I just needed to do enough to
allow this to interoperate with CFApp.
This patch removes all reliance on pgweb to search and view the
archive. It should be fairly simple to incorporate the relevant
changes into pgweb if desired but ideally this application should
provide both the archive and the user interface.
The present reliance of pgweb to generate string html and write it
out using {{html | safe}} is largely abolished in favor of proper
html element usage - divs and span with classes. Note in particular
the abstract_found and abstract_after reworking.
The added __str__ overrides on list and groups allows the drop-down
selection list to show the proper labels.
The related work in views.py is basically to continue to handle both
the pgweb/simple search interface as well as this new advanced search
interface. The search implementation has been factored out and the
new search view added for local search - leaving archive-search for pgweb.
A while back I made a feature request to limit search results to
a single message per thread. I've implemented an initial version
of that here. The advanced search page re-implemented here adds
a checkbox to enable this mode; and the results show both the
thread id and ranking within the thread, whether "oneperthread"
is checked or not.
This patch also introduces a new function named is_patch. This
uses the same exact criteria that CFBot uses. The thinking here
is that knowing which messages and threads contains patches is
useful context to use while searching or within search results.
The immediate use for this information is the newly added threads
view. Presently coded for demonstration purposes only, this view
presents the most recent threads that contain patches. With this
information it is possible, and demonstrated, to actually push
all of the needed information from pgarchvies to pgcommitfest
to create a new patch, with reasonable defaults. For the moment
it is created using CFBot as the creator but given our single
sign-on authentication filtering the thread results on user and
creating the patch with them as author should be doable.
Content-Type now gets passed around in the attachment metadata.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.