-
Notifications
You must be signed in to change notification settings - Fork 50
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
Harmony 1894 - add support for labeling jobs #630
Conversation
to avoid merge issues and add a rethrow of errors that were being captured in job saves
to the jobs table and some other cleanup
* @param labels - the array of strings representing the labels. These will be forced to lower-case. | ||
* If this is an empty array then any existing labels for the job will be cleared. | ||
*/ | ||
export async function setLabelsForJob( |
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 positive how this is going to be used, but I do not like endpoints that require you to pass in what you think should exist plus any new info.
I'd want to have an endpoint to add one or more labels without changing any existing labels and an endpoint for removing one or more labels.
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 AC for this ticket:
* when a user submits a request they can submit one or more labels for the job
* the new label parameter is documented with examples
This ticket just allows the user to set labels when making a request. So not updating things. The updates will happen in later tickets. But one of the major use cases for the other tickets is to allow users to add labels from the workflow-ui, in which case I would think the UI should show them the existing labels, which means you would have them and could resend the whole list. But if you want to do it piecemeal for some reason then that can be a different function.
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.
One thing I have tried to avoid is adding a full model for labels, since they are so simple, but if you want CRUD at the label level then maybe we should make a full model.
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 tested things out successfully in a sandbox environment. I ran into one issue with a 500 error returned (I assume because of the 255 character limit) when passing in a wall of text for the label. I think we have two options:
- Reject the request with a 400 error and say each label is limited to 255 characters
- Accept the request and truncate the label to 255 characters
I vote for option 1. I was already thinking that I should add a line in the docs about the 255 character limit. |
`value` varchar(255) not null, | ||
`createdAt` datetime not null, | ||
`updatedAt` datetime not null, | ||
UNIQUE(username, value) |
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.
Why don't we make the value itself be the unique 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.
What is the use case of username and value?
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.
If we did that then only one person could be associated with the label value. We want to be able to look up the labels for a person so we can populate an autocomplete, so we need to have both value and username 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.
When I log in as an admin, I think I should see all labels rather than just mine. There will be so many duplicate label values in the table and that will make cleanup much harder.
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 get the labels for a user through the jobs table and the association with labels.
describe('update labels for job', async function () { | ||
const updatedLabels = ['baz', 'buzz']; | ||
it('updates the labels for the job', async function () { | ||
await setLabelsForJob(this.trx, this.job.jobID, this.job.username, labels); |
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.
nit: We can remove this line if we make the whole test a transaction with three steps and I think the test will be more readable if we do that.
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 like for tests to not rely on other tests setting things up in the database. It makes them too fragile.
if (!labels) return; | ||
|
||
// delete any labels that already exist for the job | ||
await transaction('jobs_labels') |
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.
what about the labels
table?
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 don't want to delete those. Labels can be re-used.
add maximum length validation
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.
Verified functionality for rejecting requests with labels greater than 255 along and verified 255 or less continued to work as expected.
Jira Issue ID
HARMONY-1894
Description
Adds a new parameter
label
that can be provided with Harmony requests (OGC Coverages/EDR) to specify one ore more labels for a job.Local Test Steps
bin/bootstrap-harmony
which will run the migrations for youFor Coverages:
For EDR (GET):
For EDR (POST):
labels
andjob_labels
and make sure you see rows for the labels you set.Here are a couple of useful queries (change the labels to whatever you used):
PR Acceptance Checklist