Closed alexander-haller closed 2 months ago
In GitLab by @mhxion on Apr 2, 2024, 15:53
requested review from @alexander-haller
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 2, 2024, 16:22
added 1 commit
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 2, 2024, 18:39
added 1 commit
approved this merge request
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 8, 2024, 02:23
added 16 commits
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 8, 2024, 17:55
added 2 commits
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 10, 2024, 20:30
added 5 commits
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 10, 2024, 20:36
added 2 commits
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 10, 2024, 22:18
added 1 commit
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 11, 2024, 01:16
added 1 commit
In GitLab by @mhxion on Apr 11, 2024, 01:19
requested review from @alexander-haller
In GitLab by @mhxion on Apr 11, 2024, 01:22
I have updated the description with details of store-info
. We can discuss it in tomorrow's meeting as always.
In GitLab by @project_994_bot_1f89ebd5af89f5e987c71c650dd64895 on Apr 11, 2024, 02:16
added 2 commits
In GitLab by @mhxion on Apr 11, 2024, 12:11
requested review from @alexander-haller
In GitLab by @ghost on Apr 11, 2024, 13:32
added 1 commit
In GitLab by @project_994_bot_1c5bd6ac1fdbd740fbc4ed080ecff58d on Apr 11, 2024, 20:06
added 5 commits
In GitLab by @mhxion on Apr 11, 2024, 20:09
Fixed/added:
.tmp_<...>
correctly/dev/urandom
store-info
In GitLab by @project_994_bot_1c5bd6ac1fdbd740fbc4ed080ecff58d on Apr 11, 2024, 23:43
added 2 commits
In GitLab by @mhxion on Apr 14, 2024, 15:59
added 4 commits
In GitLab by @project_994_bot_1c5bd6ac1fdbd740fbc4ed080ecff58d on Apr 14, 2024, 16:21
added 1 commit
In GitLab by @project_994_bot_1c5bd6ac1fdbd740fbc4ed080ecff58d on Apr 14, 2024, 16:29
added 1 commit
In GitLab by @mhxion on Apr 14, 2024, 17:50
We are good to go (:
In GitLab by @mhxion on Apr 2, 2024, 15:52
Merges new-bill-teams -> dev
This PR doesn't introduce all the necessary changes to
bill-teams
command yet, as it is still WIP. I have made small but related and imported changes that I intend to discuss in this PR instead of opening multiple separate PRs. I will update the description and make a new review request when a new change has been concluded and pushed to the PR.1. Restrict
host
URL for testingSince I am using multiple
elapi.yml
configuration files, it slips my mind sometimes exactly whichhost
URL I am targeting, namely if I am targeting a dev instance or the production instance!show-config
alleviates that confusion but I still sometimes find myself running code often times without properly checkingshow-config
first. I believe others (especially people writing automation scripts using elAPI) might find themselves in the same situation.So, I introduce a simple and straightforward way to restrict running any code to some predefined
host
URLs. Examples:• Validate
host
without restrictionHostIdentityValidator
validation class was introduced inv1.0
.HostIdentityValidator
checks if givenhost
andapi_token
inelapi.yml
are without errors. E.g., if there's a typo inhost
or an expiredapi_token
is being used,HostIdentityValidator
will immediately throw a validation error and will stop elAPI from proceeding. The following is the most basic use-case:• Validate
host
restricting to development instance onlyWe modify
HostIdentityValidator
to add support for this restriction feature.The above validation will throw validation error, if the detected
host
fromelapi.yml
file is anything besides"https://elabftw-dev-002.uni-heidelberg.de/api/v2"
. Now we can confidently run any code without having to worry about if we are accidentally making changes to production.• Validate
host
restricting to multiple instancesWe can also pass multiple URLs and a validation error will be raised, if detected
host
URL is not either of the givenrestrict_to
URLs.Note
This
restrict_to
parameter is mainly intended for when the developer is in testing phase. When the a script is ready and stable, the developer does not need to put any restriction in most cases. We also don't ship any stable build whererestrict_to
has been used!2.
store-info
store-info
works and behaves the same way as we've discussed so far.elapi bill-teams store-info --help
explains the basic usage.store-info
accepts the following arguments:--root-dir
: The root of the directory where store-info will create the billing directory hierarchy.--meta-source
: Source path for owners information CSV file. Internally referred to as the 'billing metadata'. --meta-source is not required when--teams-info-only
is passed, otherwise it is required.--target-date
: ISO 8604 'YYYY-MM' for which 'YYYY/MM' directory to store.--teams-info-only
: If passed, then only teams-info will be stored.Both--teams-info-only
and--owners-info-only
cannot be passed--owners-info-only
: If passed, then only owners-info will be stored. Both--teams-info-only
and--owners-info-only
cannot be passed.• Basic usage
elapi bill-teams store-info --root-dir ~/bill-teams --meta-source <CSV file path to owners information>
will store the information in the following structure:• Fix mistake of previous month
Let's assume we've the following information stored for 2024-04 to 2024 2024-05.
In May 11, 2024, at 10:51 AM, we find out we've made mistake in April 2024 in our owners information (metadata) collection. We would like to inject the corrected owners information into April's directory.
The above will add a new
owners_info
JSON file inside04
directory.The file name prefix
2024-05-11_105122
in2024-05-11_105122_owners_info.json
will indicate the upcominggenerate-table
sub-command that2024-05-11_105122_owners_info.json
is latestowners_info
metadata file for April 2024. This way we can avoid having to manually edit the JSON files, and it gives us a Git-like clean version history. Though modifying the JSON files are always an option.Notes
store-info
sub-command makes sure that the given path to--root-dir
is indeed a directory and not a file, if it can actually write inside given--root-dir
, thanks to elAPI's library-wide path validator. E.g.,--root-dir /foo
will fail and show error message "--root-dir path '/' could not be validated! Data could not be stored in desired location." elapi will abort if--root-dir
is invalid.--target-date
, but anything besides the year and month is ignored. E.g., if--target-date 2024-04-11T01:14:21.244220
is passed, the entire11T01:14:21.244220
part will be silently ignored.--teams-info-only
and--owners-info-only
are passed,store-info
will show an appropriate error message and abort.