search

openedx / frontend-app-authoring

Front-end for the Open edX Studio experience, implemented in React and Paragon.
GNU Affero General Public License v3.0
13 stars 70 forks source link

Component Sidebar: Details Tab #1195

Open jmakowski1123 opened 1 month ago

jmakowski1123 commented 1 month ago

To be completed after: https://github.com/openedx/frontend-app-course-authoring/issues/1045

  1. The Details Tab contains a free-text field for users to enter a description of the content.
  2. Field for content type
  3. Links to courses where the component is being used
  4. Time stamp for last modified
  5. Time stamp for created

Image

Out of scope: The "Creator" of the component is excluded for now (not stored anywhere) discussion

rpenido commented 1 month ago

Hi @bradenmacdonald!

  1. Links to courses where the component is being used

Just to confirm, I think this is out of scope for Epic 3. We need https://github.com/openedx/frontend-app-course-authoring/issues/1185 to have this info, right?

bradenmacdonald commented 1 month ago

@rpenido That's right.

rpenido commented 1 day ago

Hi @bradenmacdonald! I have another doubt that I want to confirm here:

  1. The Details Tab contains a free-text field for users to enter a description of the content.

It doesn't seem that the XBlock has a description field, and currently, we are rendering the content in the Component Card. Should we change it and use a new description meta field?

bradenmacdonald commented 1 day ago

@rpenido Yes, the plan was to have the description field that can override the one that comes from the content. Setting the description doesn't change the XBlock [fields] at all - it's only a change in the library metadata.

But I think we thought at the time that ComponentVersion had a description field and now I see that it doesn't. @ormsbee or @kdmccormick do you remember what we discussed about this? Should we add a description field to Component or ComponentVersion or punt this for now?

ormsbee commented 15 hours ago

Asked for clarifications in Slack, but my off-the-cuff take is that the description is a field on a new model that's 1:1 with Component–mostly because a lot of queries will potentially join against Component, and I'd be worried about the descriptions text coming across the wire by default for all of them. (I realize we can defer fields in the queryset, but I worry about other things that hang off of ComponentVersion not realizing how careful they have to be about that in their RelatedManagers.)