This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Maybe task number 3 can be done later. It could also change the UX, instead of instantly loading the imported requirements we need to show some kind of alert that let the user know the import is happening.
@felipe_artur Sounds good to me, I'll go ahead and create the issues, assuming the step 1 is going to be included in this issue that is shared with frontend
@felipe_artur@egrieff I agree the operation should be asynchronous, I wonder if we need to address #249182 (closed)
when exposing graphql API for import (together with #249181) instead of addressing it later? The reason is that API behavior/response of the mutation would be different depending on whether import is synchronous or asynchronous operation (for sync processing we could return list of errors and whether the operation succeeded, for async operation we can return just whether the operation was queued for execution and maybe link to the async job) so switching from sync to async later would be a breaking API change. 🤔
@jprovaznik Yeah, that's a good point. Actually, I was going to address #249182 (closed) together with this issue because building it synchronous is similar work to building it asynchronously so I thought it was better to have it ready from the start. Would that block your progress on #249181?
@egrieff no, that's fine 👍 - from GraphQL API I can just stub the service (leave it empty) and put it behind a feature flag. It's little bit tricky in this case to figure out some reasonable vertical breakdown of this feature.
@egrieff based on the description this issue covers the business logic of the feature (implement import service plus #249182 (closed)) so it can't be used by users yet - so no feature flag is needed of this one. But when #249181 is added, users will be able to use the endpoint - so it should be either done when this issue is finished #246857 (closed) (or as part of it :) or if it's meant to be worked in parallel a feature flag would be an option too. Whichever option is fine by me, or maybe if you prefer to work on #249181 when you finish this one, that's fine too (I just picked first task from the issue board yesterday 🙂 - I can pick something else)
@mjwood Sorry for the delayed response, but I agree (with moving to %13.6)
@johnhope looks like we scheduled this for iteration 10 but seeing as it isn't assigned to anyone with just a few days left in the iteration, should we go ahead and bump it to a high priority on iteration 11?
Is there any other field that would be essential, to begin with? Maybe state?
It's possible to take an issue CSV export and upload it as a list of requirements since we only check for title and description. Are we okay with that, or are users supposed to craft their own requirements CSV?
I guess this is not the intended goal, but wouldn't be a problem if it was used this way?
My take is that we shouldn't block on it and go ahead with title and description even if we did want state in the future. I don't think it's a big deal for people for people to set the state after the import is complete, it'd be a manual process, but I can't think of why they would want to anyway. But we can always do a fast-follow and iterate on the solution you have.
I think this might even be a useful feature for anyone who has been using issues in place of requirements thus far. I don't see any reason why this would be a problem but maybe @mjwood does?
My take is that we shouldn't block on it and go ahead with title and description even if we did want state in the future
Thanks @johnhope, I agree that if what we need is additional we can move on with this MR given it's already at the last stage of reviewing and blocking 3 other MRs.
I think this might even be a useful feature for anyone who has been using issues in place of requirements thus far. I don't see any reason why this would be a problem
I thought that as well but I'm not that knowledgeable about the usage of requirements 😅
Update: The first iteration for backend has been merged !46361 (merged) and the MR that adds email notifications is currently in review: !46484 (merged)
@egrieff I think if they can create requirements they should probably be able to import them. Reporters can also create/update/delete epics, issues and MRs so I think it's an appropriate access level.
The other two issues for this feature #249182 (closed) & #249181 have MRs progress, but the Sidekiq job had some complications and it's needed for the GraphQL mutation so both have been delayed.
For issues import, we currently use a controller upload and might be the most direct option from a backend perspective. @rajatgitlab maybe you can add your input for a preferred choice? 🙇
Also, as the work for the Sidekiq job is being blocked by a problem introduced in !46361 (merged), it's not very likely to have all required backend work merged before the cut-off date for %13.6.
Thanks for update @egrieff, I didn't know about this limitation.
For issues import, we currently use a controller upload and might be the most direct option from a backend perspective.
I agree that private API (controlller) would be better in this case:
we don't have REST API for requirements so we would have to add basic endpoints and requirement entity
once we add it to REST API we couldn't remove it easily. So using temporarily private API (we already have ee/app/controllers/projects/requirements_management/requirements_controller.rb) for uploads and when #280819 just replace with GraphQL API call would be simpler