-
Notifications
You must be signed in to change notification settings - Fork 54
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
Feature/versioning #779
Feature/versioning #779
Conversation
I find that this PR makes it so, that we can't run any rake tasks at build time as there is no database available and the initalizer seems to require one. |
Additional Info: My theory - and this can also just be complete and utter garbage - is this: The log of the relevant error that occurs is this:
|
Using this with an empty database fails, running the migrations again seems to fix it, but that's not how it should be. SUPER LONG LOG IS HERE
|
This commit refactors `ReactionDetails` and `SampleDetails` to make them pass eslint checks. We had unused functions there, which will be removed by this commit: - SampleDetails#initiateAnalysisButton - SampleDetails#initiateAnalysisWithKind - SampleDetails#transferToDeviceButton Also disables `forbid-prop-types` in .eslintrc for now. This can be taken out later, when we can better specify the propTypes across the entire project.
Store a history which keeps track of every change made to certain entities and add a "History" tab to the Reaction/Sample detail pages. Related entities are displayed in the version history. E.g. Reaction -> ReactionsSample Save timestamp and author of the version with the changes. A change diff to the previous version can be displayed. Tracked entities: - Attachment - Container - ElementalComposition - Reaction - ReactionsSample - Residue - Sample Co-authored-by: VadimKeller <[email protected]>
38a77fe
to
8813eaf
Compare
moved to #1253 |
rather 1-story 1-commit than sub-atomic commits
commit title is meaningful => git history search
commit description is helpful => helps the reviewer to understand the changes
code is up-to-date with the latest developments of the target branch (rebased to it or whatever) => ⏩-merge for linear history is favoured
added code is linted
tests are passing (at least locally): we still have some random test failure on CI. thinking of asking spec/examples.txt to be commited
in case the changes are visible to the end-user, video or screenshots should be added to the PR => helps with user testing
testing coverage improvement is improved.
CHANGELOG : add a bullet point on top (optional: reference to github issue/PR )
parallele PR for documentation on docusaurus if the feature/fix is tagged for a release