Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Forms to construct Pub view #1035

Open
gabestein opened this issue Mar 6, 2025 · 5 comments · May be fixed by #1070
Open

Use Forms to construct Pub view #1035

gabestein opened this issue Mar 6, 2025 · 5 comments · May be fixed by #1070
Assignees

Comments

@gabestein
Copy link
Member

gabestein commented Mar 6, 2025

Motivation

So admins can specify specific views for Pubs
So users (authors, reviewers, copyeditors, etc.) can view Pubs in specific, focused contexts based on their role
So developers can determine what related fields to show users without running into graph problems

Requirements

  • Uses the order, and label, of fields on a form to order the fields on the view page and display their labels
  • If the user is a contributor (at any level), only shows the fields specified on the form
  • Removes the "related pubs/section" table for contributor users
  • For other users, shows the fields not on the form at the bottom of the page, in a section called "Other Fields"
  • Defaults to the default form for any given type
  • If no form exists for a type, create default form for pub type and use that

Acceptance Criteria

  • Fields are displayed using current form field renderers -- in the future we will return to creating read-only views

Mockups (if available)

Image

@tefkah
Copy link
Member

tefkah commented Mar 10, 2025

Making read-only versions of the current form inputs might prove to be a large part of this. eg the related pub and context-editor inputs.

for the related pub inputs as views, should we allow users to view more information about those pubs, or is it just "clicking through"?

@3mcd 3mcd added the 3-day label Mar 10, 2025
@gabestein
Copy link
Member Author

Agreed. We're gonna strip this down to use current renderers for now, and then return to more friendly views later.

@allisonking
Copy link
Contributor

a few questions:

  1. What should this look like if the form has a field but there is no value? Should we only render the label, i.e.

Image

(here there is no MemberId value)

  1. We've been omitting the title when rendering pub values since the title is hoisted to the top header. do we still want to do this?

Image

In this picture, we're rendering both the title (James McJimothy) hoisted up, as well as the title because the form has the title.

@allisonking
Copy link
Contributor

Fields are displayed using current form field renderers -- in the future we will return to creating read-only views

Does this refer to the current view renderer or the form renderer? i.e.

Image

or

Image

@gabestein
Copy link
Member Author

What should this look like if the form has a field but there is no value? Should we only render the label, i.e.

Label only for now, but let's add an empty paragraph's worth of margin below it so it stands out more, and we'll let @ktyjscott spiff it up later.

We've been omitting the title when rendering pub values since the title is hoisted to the top header. do we still want to do this?

Let's continue current behavior, yes. Perhaps we'll add a setting to "include title field" on the form in the future, but seems like a heck of an edge case to me.

Does this refer to the current view renderer or the form renderer? i.e.

Current view renderer. Otherwise this would be a much longer ticket. We'll replace these renderers over time as we get into the context atoms etc.

@allisonking allisonking linked a pull request Mar 13, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

4 participants