| Age | Commit message (Collapse) | Author |
|---|
|
Build a breadcrumb. In order to do so, we need to set the `@line`
instance variable (how would I know that? I wouldn't, damn implicit
dependencies).
Refs #4189
|
|
Set header text in the locale files and display it on the page given the
route ID in the URL. Remove the third argument from `pageheader` because
after looking at the helper method's signature, I see that it's not
necessary.
Refs #4189
|
|
Duplicate of new.html.slim for now just to get the page working.
Refs #4189
|
|
|
|
Don't force creation of the `route`, create it lazily.
Refs #4189
|
|
This test was commented out in 2015. Safe to say we can remove it now.
|
|
|
|
This method was commented out in 2012. Safe to say we can remove it.
|
|
A couple of new routes for a form that will allow us to duplicate an
itinéraire/route inside a line.
Refs #4189
|
|
|
|
|
|
|
|
|
|
|
|
4216 rename attributs
|
|
af83/3511-cron-job-to-notify-parent-WorkbenchImport-of-sub-import-status--rb201708011853
3511 cron job to notify parent workbench import of sub import status rb201708011853
|
|
af83/3507-update-rails_host-config-variable-and-workbench-import-zip-files-from-pull-request-comments
3507 update rails host config variable and workbench import zip files from pull request comments
|
|
|
|
|
|
|
|
`message_attributes` in code (not migration or schema!!!)
|
|
Removed Dead Code Factories `clean_up_results` & `import_messages`
|
|
4176 1726 neteximp autocreate ref
|
|
|
|
Refs #3509, #3511
|
|
Instead of manually defining the finished statuses, use the method
that's already defined on `Import` to get them.
The only unfortunate part is that we now had to muss up our `Import`
code and convert those methods to class methods in order for them to be
accessible to `ParentImportNotifier` as well as its instance methods.
Refs #3511
|
|
development.rb
|
|
Make Robert happy :)
Refs #3511
|
|
I'm still not a fan of these myself, but let's make Robert happy.
Refs #3511
|
|
At Robert's suggestion, convert these methods to RSpec shared examples.
I had thought about using shared examples when I originally wanted to
write these tests, but was trying to get things working quickly and
couldn't figure out how to use them at the time, so I went with
something that seemed obvious to me and worked. Now we can take
advantage of the testing DSL available.
Refs #3509, #3511
|
|
This call can be written much more concisely. Thanks for the suggestion
Robert!
Refs #3511
|
|
Robert pointed out that it isn't necessary to prefix the method call
with `self.`. Makes the code cleaner.
Refs #3511
|
|
|
|
|
|
|
|
The `#notify_parent` method should update the `notified_parent_at` field
on the child import so we know not to query it in subsequent batches of
parent import notifications.
Add the Timecop gem in order to be able to safely test the DateTime
update.
Refs #3511
|
|
- Specing that, in case of a correct request Referential & NetexImport instances are created and a 201 is returned
- Specing that, in case of an incorrect request, no instance is created and a 406 with a correct error message is returned
- Implemented
MISSING:
Refactor controller implmentation
|
|
|
|
|
|
- Specing that, in case of a correct request Referential & NetexImport instances are created and a 201 is returned
- Specing that, in case of an incorrect request, no instance is created and a 406 with a correct error message is returned
- Implemented
MISSING:
Refactor controller implmentation
|
|
|
|
merge to keep a reference in feature branch)
|
|
Not sure if this could cause any problems, but it makes more sense to me
to put the helper method in the test where it's used, since that's the
only place where it's used and that test is the only reason why it
exists.
Refs #3509, #3511
|
|
Don't update the parent status if it's already been set to a finished
status. This protects against situations like this:
child_import_1 status: :failed
#child_change => parent_import status: :failed
child_import_2 status: :successful
#child_change => parent_import status: :successful
In that scenario, even though one of the parent's children had failed,
it still gets a successful status at the end. To prevent that situation,
don't update the parent's status if it's already been set to a finished
status.
Refs #3509, #3511
|
|
I had apparently committed these comments from before I had written any
tests and was thinking about what to test. Remove them.
Refs #3509, #3511
|
|
Didn't like the `flat_map` written inline in the `#failing_statuses`
method because it wasn't obvious what it was doing.
Got that from this answer by mr.musicman on Stack Overflow:
https://stackoverflow.com/questions/21816139/is-there-something-like-with-indifferent-access-for-arrays-usable-for-include/42723778#42723778
(thank you) that describes how to make an array that responds to
`#include?` for both symbols and string versions of those symbols.
Extract that logic into its own method. Leaving it in `Import` for now
because I only need it here and I didn't want to bother putting it in
another module.
Refs #3509, #3511
|
|
The `#child_change` method should update the current import (the parent)
with a 'failed' or 'successful' status depending on the status of the
child passed in.
If the child has a failure status, the parent import should be updated
to failed. If the import is `#ready?`, that tells us that all children
have called `#child_change` without any problems, and we can update the
parent's status to be successful. THAT PARAGRAPH IS WRONG. We could have
`#ready?` with failed children. NEED TO UPDATE TO SUPPORT THAT.
Add a method that describes the possible "failing" statuses. These are
the ones that will cause 'failed' to be set on the parent.
Refs #3509, #3511
|
|
This boolean method answers whether or not the current import's
`current_step` and `total_steps` fields match. If so, all of its
subtasks are finished, in which case it can be thought of as "ready".
Refs #4174, #3511
|
|
Calling `#notify_parent` should call the `#child_change` method on the
import's parent import. That `#child_change` method will tell the parent
to update itself based on the status of the child.
Refs #3511
|
|
I had started a separate `WorkbenchImport` factory in a separate branch,
but now that I've rebased on Robert's work for #3507, we need to rectify
the doubled `WorkbenchImport` factories. Use Robert's version but move
it to the "workbench_imports.rb" factory file to match the `NetexImport`
factory.
Refs #3511
|
