-
Notifications
You must be signed in to change notification settings - Fork 118
Add API V2 from DMPonline #3587
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
base: main
Are you sure you want to change the base?
Conversation
Generated by 🚫 Danger |
|
Thank you for this PR. During today's DMPRoadmap Monthly all-team meeting I mentioned how there are also related DMPTool v2 API test files. Would you like me to add them to this PR? |
|
I'm seeing a lot of rubocop errors in here. This might be a difference in the configuration of Rubocop between the Roadmap repo and DMP Online. Let me know how you'd want to approach this. If possible, I could start a PR attempting to fix these. |
|
|
||
| json.type output.output_type | ||
| json.title output.title | ||
| json.doi_url output.doi_url |
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 looks like output.doi_url will raise *** NoMethodError Exception: undefined method 'doi_url' for #<ResearchOutput ....
Does DMPonline have a doi_url method defined? If not, I'm also seeing the following code comment in app/services/external_apis/doi_service.rb:
def mint(plan:)
SecureRandom.uuid
# Minted DOIs should be stored as an Identifier. For example:
# doi_url = "#{landing_page_url}#{doi}"
# Identifier.new(identifiable: plan, value: doi_url)
# When this service is active and the above identifier is available,
# the link to the DOI will appear on the Project Details page, in plan
# exports and will become the `dmp_id` in this system's API responses
endThere 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.
Hi @aaronskiba, apologies I missed this. Not sure why it didn't throw an error when I tested it. Please remove line 10 json.doi_url output.doi_url from app/views/api/v2/datasets/_show.json.jbuilder because it's from the DOI in research outputs feature that we added in DMPonline. The DOI feature was meant to be shared back to roadmap by now in a different PR, that's why it's missing.
Regarding the file app/services/external_apis/doi_service.rb, this is not part of the API V2 code. It's part of something Brian worked on for DOI minting.
|
Here is the document with the API calls. Please let us know if needs changing |
@momo3404 apologies we missed this. I can do this and push it back next week, if that's ok. |
|
These two docs are more for developers support. It might be useful |
Awesome, thank you. Sorry, the links got a little bungled up in the comment. :P |
@aaronskiba Here you go: Let us know if this doesn't work. |
|
I'm encountering the following when I test the App backtrace
Full backtrace |
| # Remove `null: false` if you are planning to use grant flows | ||
| # that doesn't require redirect URI to be used during authorization | ||
| # like Client Credentials flow or Resource Owner Password. | ||
| t.text :redirect_uri, null: false |
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.
Since we will be implementing the v2 API Client Credentials Flow in a future piece of work, maybe we should remove null: false on redirect_uri, as the code comment advises.
| respond_to :json | ||
|
|
||
| # GET /api/v2/templates | ||
| def index |
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 no route defined for this in config/routes.rb. I think we need something like resources :templates, only: :index inside of namespace :v2 do.
|
|
||
| # json.items [] | ||
| json.message @payload[:message] | ||
| json.details @payload[:details] |
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 can see @payload[:message] being assigned within app/controllers/api/v2/base_api_controller.rb. But is @payload[:details] being set anywhere? Maybe it can be removed.
| @client = OauthApplication.find(doorkeeper_token.application_id) if doorkeeper_token | ||
| @scopes = doorkeeper_token.scopes.to_a if doorkeeper_token | ||
| return unless doorkeeper_token&.resource_owner_id | ||
|
|
||
| @resource_owner = User.find(doorkeeper_token.resource_owner_id) |
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 guess this could be refactored. An outer if doorkeeper_token could be used to replace the repeated if doorkeeper_token checks.
| # created_at: :datetime | ||
| # updated_at: :datetime | ||
|
|
||
| class OauthApplication < ApplicationRecord |
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 a little worried about directly inheriting from ApplicationRecord and simply mapping to the Doorkeeper tables in app/models/oauth_access_grant.rb, app/models/oauth_access_token.rb, and app/models/oauth_application.rb. These classes will not include Doorkeeper’s behaviour (validations, associations, etc.).
Currently, @client = OauthApplication.find(doorkeeper_token.application_id) if doorkeeper_token appears to be the only code that references these models (see app/controllers/api/v2/base_api_controller.rb), which should be safe. But I worry about issues arising in the future.
Unless this was implemented for a specific reason, I might suggest one of the following:
- Remove these classes altogether
- These tables/models can instead be referenced via
Doorkeeper::Application,Doorkeeper::AccessToken;, andDoorkeeper::AccessGrant. (e.g.@client = Doorkeeper::Application.find(doorkeeper_token.application_id) if doorkeeper_token)
- Update each of the classes to inherit from the appropriate
Doorkeeper::Application,Doorkeeper::AccessToken;, orDoorkeeper::AccessGrant.
class OauthApplication < Doorkeeper::Application; end
class OauthAccessToken < Doorkeeper::AccessToken; end
class OauthAccessGrant < Doorkeeper::AccessGrant; end| Plan.joins(:roles) | ||
| .where(roles: { user_id: @resource_owner.id, active: true }) | ||
| .distinct |
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 might be even better to reuse the Plan.active(@resource_owner) scope for this query. Note that a bit of refactoring could be performed in that scope to make this more efficient (i.e. don't use includes(:template, :roles))
|
Please let me know if I've done something wrong here, but I keep getting 302s when executing the GET command from the Authorization Code Grant Flow. But the command still worked, because after calling |
| end | ||
|
|
||
| json.template_id do | ||
| identifier = Api::V2::ConversionService.to_identifier(context: @application, |
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 think @application will evaluate to nil here.
I can see that app/controllers/api/v1/base_api_controller.rb sets @application = ApplicationService.application_name, whereas app/controllers/api/v2/base_api_controller.rb is setting @server = ApplicationService.application_name.
PR for issue #3586
This issue branch uses the doorkeeper gem to implement the Authorization Code Grant Flow (ACGF) part of the v2 API.
(The Client Credentials Flow (CCF) part of the v2 API (which is what the org-admins will use) will be implemented separately in a future piece of work.)