-
Notifications
You must be signed in to change notification settings - Fork 19
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
Show labeler info in labels and adjust color coding #61
Conversation
Your Render PR Server URL is https://ozone-staging-pr-61.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cnsd1eo21fec73aadh40. |
Your Render PR Server URL is https://ozone-sandbox-pr-61.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cnsd1fg21fec73aadh90. |
Last{' '} | ||
{subjectStatus.reviewState === | ||
ToolsOzoneModerationDefs.REVIEWNONE | ||
? 'event' | ||
: 'reviewed'}{' '} | ||
at:{' '} | ||
{dateFormatter.format( | ||
new Date(subjectStatus.lastReviewedAt), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is lastReviewedAt
set when the review state is REVIEWNONE
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep.
{currentLabels.map((label) => { | ||
const labelGroup = getLabelGroupInfo(unFlagSelfLabel(label)) | ||
{allLabels.map((label) => { | ||
// const labelGroup = getLabelGroupInfo(unFlagSelfLabel(label)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// const labelGroup = getLabelGroupInfo(unFlagSelfLabel(label)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought I saw this get cleaned-up too, but it's still here. Maybe some changes ended-up getting clobbered?
components/common/labels/List.tsx
Outdated
<h4 className="leading-4"> | ||
<b>{label.val}</b> label does not have a custom definition. Users | ||
will be able to configure the behavior of the label in app. | ||
</h4> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure whether this is accurate—we might want to check in with Paul/Bryan about the right way of messaging around this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's not. some labels are configurable in app though so changed the text from `will be" to "may be" which should have us covered.
if (labelerDef?.policies.labelValueDefinitions) { | ||
const definitionsById: Record< | ||
string, | ||
ComAtprotoLabelDefs.LabelValueDefinition | ||
> = {} | ||
labelerDef.policies.labelValueDefinitions.forEach((def) => { | ||
definitionsById[def.identifier] = def | ||
}) | ||
labelerDef.policies.definitionById = definitionsById | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there something in particular that we find in here that we aren't able to get from session.config.labeler
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, the idea of this PR is that eventually, we could plug in other labelers into ozone. Bryan touched on this I think somewhere that other labelers may want to see labels added by bluesky.
there's a bit more work left to get this all to work and get the backend to send labels from other labelers but once that's done, this will make more sense I think.
<ModerationLabel | ||
recordAuthorDid={item.post.author.did} | ||
label={label} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this needs a key
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a key, the last prop.
lib/constants.ts
Outdated
export const OZONE_SERVICE_DID = | ||
process.env.NEXT_PUBLIC_OZONE_SERVICE_DID || | ||
'did:plc:ar7c4by46qjdydhdevvrndac' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that we need to hardcode our labeler in Ozone. The service DID may also be set at runtime by fetching ozone-metadata.json
, as is the case when running the dockerized Ozone distribution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooops... accidental commit, will clean up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@foysalit I thought I saw this get cleaned-up, but it still is kicking around here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yh idk what's up but I think I lost some changes when merging main into this.
const builtIn = ozoneDid || OZONE_SERVICE_DID | ||
return await getConfig(builtIn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the Ozone distribution we need to leave the possibility open that builtIn
is not set, and may be determined at runtime within getConfig
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, cleaning up the fallback of service did to our labeler should be enough for that, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The functionality here is awesome! Just a couple questions for us to answer around runtime configuration and a bit of copy in the app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is really great! nice polish
components/mod-event/EventItem.tsx
Outdated
// Moderation events being displayed means that these events were added by the current service | ||
// so we can assume that the src is the same as the configured ozone service DID | ||
return ( | ||
<LabelChip key={label} style={{ color: labelGroup.color }}> | ||
{displayLabel(label)} | ||
</LabelChip> | ||
<ModerationLabel | ||
key={label} | ||
label={{ val: label, src: OZONE_SERVICE_DID, uri: '', cts: '' }} | ||
/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we'll be able to capture the "current service" using a constant, since it may be determined at runtime. I think there's a useSession()
hook kicking around that we could use to grab it, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can also just get it from client
directly, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
This PR fetches labeler service details and shows info about the service and the label along with any label on contents to make it easier for moderators to skim through labels.
NOTE: As a side effect of behavior based color coding, this PR removes hard coded color coding based on label categories. This is based on the fact that 3rd parties running the service won't benefit from any of the color coding and our own moderators don't seem to rely on the color coding much.