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

Jobs published via API are missing fields in the Career Portal #234

Closed
LakenH opened this issue Oct 25, 2018 · 8 comments
Closed

Jobs published via API are missing fields in the Career Portal #234

LakenH opened this issue Oct 25, 2018 · 8 comments

Comments

@LakenH
Copy link

LakenH commented Oct 25, 2018

Another client of mine uses Fyre to automatically publish jobs on Bullhorn to their career portal. However, it appears that jobs published this way do not have certain critical fields, particularly dateLastPublished and publishedCategory which the job board API has in the response for the search/JobOrder endpoint.

Current behavior

  • If a job is programmatically published, it doesn't have the dateLastPublished and publishedCategory fields
  • This also breaks the default sorting of the career portal, as it sorts by the dateLastPublished value. This can temporarily at least be fixed via changing the sorting to the job's ID, as that auto-increments, but it doesn't help the lack of category filtering for these listings.

Expected behavior

  • These fields are present, no matter what method the job is published with.

Steps to replicate behavior

  1. Have a job published via the API (Fyre was used in particular by this client)
  2. Notice lack of those fields present on the career portal's listing of that job

Screenshots

Current
https://i.imgur.com/BWrqrpY.png

Expected
https://i.imgur.com/znRUbzB.png

@charlesabarnes
Copy link
Contributor

I appreciate the detailed bug report! I am looking into this now and will provide updates as I receive them.

@LakenH
Copy link
Author

LakenH commented Oct 26, 2018

No problem! I understand the importance of a detailed bug report, due to personal experience in open source.

Do you have any updates yet? This is quite the pain-point for the client.

I also understand it's a Friday, and if it is an API bug, I do not expect an API change on a Friday afternoon. I would at least like a general idea of findings so far, if any.

Thanks :)

@charlesabarnes
Copy link
Contributor

Hey @LakenH,

I have brought this to the attention to the Fyre team and they are currently reviewing this. In the interim, I am currently looking into an approach to handle this on the frontend.

What I am thinking about is adding a configuration option to sort based on any field that's desired. That way you can sort based on job title. I also plan to add a "no category" category. While this will not tag the category data onto the job, it at least leaves them to be searchable.

@LakenH
Copy link
Author

LakenH commented Oct 26, 2018

Thank you very much for the update!

A more configurable sort would be a great improvement to the front end, in my opinion. For something relatively simple once in the angular project, it involves quite a bit of tooling (gulp, etc.) for a non-developer to change.

@LakenH
Copy link
Author

LakenH commented Oct 29, 2018

Not sure if this should be a separate issue or not, but it also seems related to Fyre's filling of fields, and how the career portal handles them...

Fyre can/will push values that shouldn't be possible under normal circumstances within Bullhorn. An example is locations (but it's also present with job types, and possibly more). There is error handling in manual entry through Bullhorn directly, but not when created with the API.

For example, Bullhorn expects the "state" to be the full name, not the 2 digit abbreviation. In this client's portal, there are some jobs that are marked as in "MA" and others in "Massachusetts" when they should be the same. In fact, virtually every location is put in as the 2-digit abbreviation instead of the full name (as they were created via Fyre). This is causing some bizarre issues with location filtering, especially due to the fact that we've replaced the sidebar's location filters with states only (due to a large number of individual locations). It would be easier to simply update the location for these few jobs with the full state name (as all others are the 2-digit code), but that isn't possible through Bullhorn.

Portal-wise, an angular filter which merges US state abbreviations with the full name is a remedy for now, but it's still not completely ideal. I'd also really like to see a default for state-level filtering in the sidebar as an option, and I see it's an often requested feature. My implementation works, but I'm sure there are better ways than my method.

@bvkimball
Copy link
Contributor

So the API doesn't actually restrict the "state" field to be one of the values in the displayOptions. It is the UI that provides those values to the User.

So through the API you can set state to any text value. The are two state pickers available in Bullhorn one that uses full state text and one that uses the US abbreviations.

I believe you can fix this a few ways, 1. You can add a mapping in Fyre to set values received from VMS to the appropriate value in you configuration. or 2. you can make a Form Trigger in Bullhorn to perform the mapping on save.

@bshevlin
Copy link

bshevlin commented Oct 31, 2018

Fyre does have a simple option per client to use full state names instead of the abbreviations.

As for the other fields, it's easy for us to configure a rule to always set dateLastPublished to the current date when we upload a job.

If there are a only a few options for publishedCategory that are simple to determine and don't change, we can set up conditional rules to set it. If not, we can always set it to some default value and let users update it if needed.

@charlesabarnes
Copy link
Contributor

With @bshevlin and @bvkimball 's answers along with the sort config option in the recent update, hopefully this addresses your concerns with getting data from Fyre to Bullhorn in an expected way.

Please let us know if you have any more questions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants