Typing will be handy in further development, as well will i settle down
to sqlite3.Row. Fetchall() returns now a list(grr) with
dict-imitating/sumating objects, which you can call keys() on and will
return them, what we now already use for Backups, which comes handy.
Also Typing gives the ability to let the code even more documentate
itself. It's planned to use all over the place but i've to read myself
into it yet more to get started on that one.
It's a step in the right direction!
On every register() call the System rewrites the /home/users.txt to
reflect currently active users. Will fall apart when something
unexpected happened, but that's @helix responsibility.
It began smelling already but having some duplicate code across the
interfaces is still better than having all of it all over the place.
It enables to write specific flags which are nice to have. For example,
Import.py requires the --Import flag because it WANTS the user to read
the whole Help before it acts actually as an importer. When the user
supplies something they should know what's currently happening.
Also removes the hardcoded dependency on lib.CFG-Calls from most calls
which was already embarassingly present. Introduced some db and
cfg-variables which doesnt clutter anything but suck much less.
In future we provide a set of default arguments and a bare minimum -
config_ui as the bare minimum, default as the full blown storm.
This is rather big because it also patches several other smells
including a bug where a user from the db wouldnt be reported as existent
Moves every check regarding the imported file outside of import.py into
the validator. Also removes every follow-up checks regarding it out of
import.py.
Looks a whole lot cleaner now!
Validates now the timestamp in the import.py, doesn't insert users into
the sqlite-database before creating the systems account and checks now
for existence in the database too(unapproved users, who comes first,
gets his name first..)
and delete occurences in Import It is much tidier to look at and
doesn't clutter the Script. Is even a whole seperate task
so it does make no sense to call it in Backup when i think about it.
this could potentially result in a endless recursion when the
table isnt writeable and a lot other funny things happen
but normally and in 99,999999999% of our cases this
is totally fine
--Import depends on --file being present pointing to a valid CSV-file
that contains unique users with id's. When a user already exists
with his id, the script will fail.
It is also Backup.py-only which is reflected in the help message
test it yet and also have to do a whole lot more. e.g. write out in dry-mode
which commands are getting to run in serious-mode but build up together
correctly in the correct order
