caosdb-server merge requestshttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests2023-09-29T19:54:34Zhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/102Helper MR for MR !1012023-09-29T19:54:34ZHenrik tom WördenHelper MR for MR !101https://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/101MAINT: LinkAhead Rename2023-09-29T19:57:49ZHenrik tom WördenMAINT: LinkAhead Rename# Summary
LinkAhead Rename; First step with no action required for users.
# Focus
Due to the renaming the 'Changes' tab in this MRis basically useless. Please have a look at the changes in !113 instead. The branch of this MR is created...# Summary
LinkAhead Rename; First step with no action required for users.
# Focus
Due to the renaming the 'Changes' tab in this MRis basically useless. Please have a look at the changes in !113 instead. The branch of this MR is created from the other one by renaming the module and by creating a thin wrapper with the old name.
The main changes are:
- todo
# Test Environment
- this pipeline
- integration test [dev] against this branch: https://gitlab.indiscale.com/caosdb/src/caosdb-pyinttest/-/merge_requests/66/pipelines
# Merge Procedure
- [ ] review changes in !113
- [ ] make sure above named tests pass
- [ ] merge !112
- [ ] delete !113
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related issues
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Up-to-date JSON schema (or not necessary)
- [ ] Appropriate user and developer documentation (or not necessary)
- How do I use the software? Assume "stupid" users.
- How do I develop or debug the software? Assume novice developers.
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Appropriate user and developer documentation (or not necessary)
- [ ] The test environment setup works and the intended behavior is reproducible in the test
environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Henrik tom WördenHenrik tom Wördenhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/87Draft: MAINT: do not treat 'has' as 'which has'2023-06-26T07:49:57ZHenrik tom WördenDraft: MAINT: do not treat 'has' as 'which has'# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should ...# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should they start reading? What should
they focus on (e.g. security, performance, maintainability, user-friendliness, compliance with the
specs, finding more corner cases, concrete questions)?*
# Test Environment
*How to set up a test environment for manual testing?*
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related issues
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Up-to-date JSON schema (or not necessary)
- [ ] Appropriate user and developer documentation (or not necessary)
- How do I use the software? Assume "stupid" users.
- How do I develop or debug the software? Assume novice developers.
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Appropriate user and developer documentation (or not necessary)
- [ ] The test environment setup works and the intended behavior is reproducible in the test
environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Henrik tom WördenHenrik tom Wördenhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/77Draft: ENH: file system: import2024-03-21T00:49:20ZTimm Fitschent.fitschen@indiscale.comDraft: ENH: file system: import# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should ...# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should they start reading? What should
they focus on (e.g. security, performance, maintainability, user-friendliness, compliance with the
specs, finding more corner cases, concrete questions)?*
# Test Environment
*How to set up a test environment for manual testing?*
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related issues
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] The test environment setup works and the intended behavior is reproducible in the test
environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Refactoring of File Storage APITimm Fitschent.fitschen@indiscale.comTimm Fitschent.fitschen@indiscale.comhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/76Draft: ENH: file system: link2024-03-21T00:38:09ZTimm Fitschent.fitschen@indiscale.comDraft: ENH: file system: link# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should ...# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should they start reading? What should
they focus on (e.g. security, performance, maintainability, user-friendliness, compliance with the
specs, finding more corner cases, concrete questions)?*
# Test Environment
*How to set up a test environment for manual testing?*
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related issues
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] The test environment setup works and the intended behavior is reproducible in the test
environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Refactoring of File Storage APITimm Fitschent.fitschen@indiscale.comTimm Fitschent.fitschen@indiscale.comhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/75Draft: ENH: file system: core2024-03-20T23:37:44ZTimm Fitschent.fitschen@indiscale.comDraft: ENH: file system: core# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should ...# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should they start reading? What should
they focus on (e.g. security, performance, maintainability, user-friendliness, compliance with the
specs, finding more corner cases, concrete questions)?*
# Test Environment
*How to set up a test environment for manual testing?*
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related issues
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] The test environment setup works and the intended behavior is reproducible in the test
environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Refactoring of File Storage APITimm Fitschent.fitschen@indiscale.comTimm Fitschent.fitschen@indiscale.comhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/74Draft: ENH: file system: directory2024-03-21T00:23:38ZTimm Fitschent.fitschen@indiscale.comDraft: ENH: file system: directory# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should ...# Summary
*Insert a meaningful description for this merge request here: What is the new/changed behavior?
Which bug has been fixed? Are there related issues?*
# Focus
*Point the reviewer to the core of the code change. Where should they start reading? What should
they focus on (e.g. security, performance, maintainability, user-friendliness, compliance with the
specs, finding more corner cases, concrete questions)?*
# Test Environment
*How to set up a test environment for manual testing?*
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related issues
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] The test environment setup works and the intended behavior is reproducible in the test
environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Refactoring of File Storage APITimm Fitschent.fitschen@indiscale.comTimm Fitschent.fitschen@indiscale.comhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/73Draft: file system: cleanup2024-03-20T23:35:10ZTimm Fitschent.fitschen@indiscale.comDraft: file system: cleanup# Summary
* Remove DropOffBox Feature
* Chown Script
* Remove Thumbnail Feature
* Refactor Checksum/Hashing Classes
# See also
* https://gitlab.indiscale.com/caosdb/src/caosdb-pyinttest/-/merge_requests/47
* https://gitlab.indiscale...# Summary
* Remove DropOffBox Feature
* Chown Script
* Remove Thumbnail Feature
* Refactor Checksum/Hashing Classes
# See also
* https://gitlab.indiscale.com/caosdb/src/caosdb-pyinttest/-/merge_requests/47
* https://gitlab.indiscale.com/caosdb/src/caosdb-pylib/-/merge_requests/83
# Focus
*Point the reviewer to the core of the code change. Where should they start reading? What should
they focus on (e.g. security, performance, maintainability, user-friendliness, compliance with the
specs, finding more corner cases, concrete questions)?*
# Test Environment
*How to set up a test environment for manual testing?*
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related issues
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md (or not necessary)
- [ ] The test environment setup works and the intended behavior is reproducible in the test
environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Refactoring of File Storage APITimm Fitschent.fitschen@indiscale.comTimm Fitschent.fitschen@indiscale.comhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/46EHN: simplify CheckPropValid and add usefull info when permission denied2021-12-06T11:11:56ZTimm Fitschent.fitschen@indiscale.comEHN: simplify CheckPropValid and add usefull info when permission denied# Summary
During debugging, I noticed that CheckPropValid does not return useful info when permission denied.
This MR simplifies the CheckPropValid.java/Job.java and add info which permission is missing.
# Test Environment
Manual tes...# Summary
During debugging, I noticed that CheckPropValid does not return useful info when permission denied.
This MR simplifies the CheckPropValid.java/Job.java and add info which permission is missing.
# Test Environment
Manual testing not necessary.
Automatic tests should be sufficient
# Check List for the Author
- [ ] All automated tests pass
- [ ] Reference related Issues
- [ ] Up-to-date CHANGELOG.md
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md
- [ ] The test environment setup works and the intended behavior is
reproducible in the test environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Timm Fitschent.fitschen@indiscale.comTimm Fitschent.fitschen@indiscale.comhttps://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/38F docs reorganize2021-10-15T08:56:17ZHenrik tom WördenF docs reorganizeI reorganized the chapters under "Specification", such that the parts that are likely to be interesting to users are further up.
Furthermore, I renamed some of them.I reorganized the chapters under "Specification", such that the parts that are likely to be interesting to users are further up.
Furthermore, I renamed some of them.https://gitlab.indiscale.com/caosdb/src/caosdb-server/-/merge_requests/33Draft: Fix extern 128 (change own password)2022-02-09T13:45:33ZTimm Fitschent.fitschen@indiscale.comDraft: Fix extern 128 (change own password)# Summary
Fix for https://gitlab.com/caosdb/caosdb-server/-/issues/128
# Focus
Point the reviewer to the core of the code change. Where should they start
reading? What should they focus on (e.g. security, performance,
main...# Summary
Fix for https://gitlab.com/caosdb/caosdb-server/-/issues/128
# Focus
Point the reviewer to the core of the code change. Where should they start
reading? What should they focus on (e.g. security, performance,
maintainability, user-friendliness, compliance with the specs, finding more
corner cases, concrete questions)?
# Test Environment
* Integration tests in https://gitlab.indiscale.com/caosdb/src/caosdb-pyinttest/-/merge_requests/15
# Check List for the Author
Please, prepare your MR for a review. Be sure to write a summary and a
focus and create gitlab comments for the reviewer. They should guide the
reviewer through the changes, explain your changes and also point out open
questions. For further good practices have a look at [our review
guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md)
- [ ] All automated tests pass
- [ ] Reference related Issues
- [ ] Up-to-date CHANGELOG.md
- [ ] Annotations in code (Gitlab comments)
- Intent of new code
- Problems with old code
- Why this implementation?
# Check List for the Reviewer
- [ ] I understand the intent of this MR
- [ ] All automated tests pass
- [ ] Up-to-date CHANGELOG.md
- [ ] The test environment setup works and the intended behavior is
reproducible in the test environment
- [ ] In-code documentation and comments are up-to-date.
- [ ] Check: Are there specifications? Are they satisfied?
For further good practices have a look at [our review guidelines](https://gitlab.com/caosdb/caosdb/-/blob/dev/REVIEW_GUIDELINES.md).Timm Fitschent.fitschen@indiscale.comTimm Fitschent.fitschen@indiscale.com