Qualification default expiration time

[samuelson-ben]

Hi,
here a pr for the topic of the qualification requests.

As part of it, it would be suitable to have a default expiration time in the core so not every plugin as to build it itself.

See also ephios-dev/ephios-qualification-fixtures#7 as the changes for the import repo.

Please look over it and give some feedback.

I know the way I solved the dilemma between having a fixed time and a set at the end of year isn't great but I don't want to introduce many new fields and it should be able to set something like the 15. May of the following year and end of year or month wouldn't be suitable.

I am open for other ideas.

[felixrindt]

Thanks for taking the time coming up with a scheme to store default expiration durations. I do like the flexibility you built into the scheme.

• If we introduce a default expiration to the model it should be part of the Qualification form in a way that non technical people can easily understand how it works. I don't think that's the case here. We could provide some multipart widget that offers selection of different modes.
• With that in mind, I wish the model can be simpler than what you suggest. What would anyone need a fixed year or relative days for? I can probably think of something, but what were your thoughts?
• We should also provide a function that applies this default duration to a start date. That shouldn't be part of your plugin. But what would the start date actually be when adding a qualification to a user? The time of editing the QualificationGrant? Should we also save the date from which the grant is valid?
• model-wise, I'm not happy with having this complex datatype as a plain charfield with validator. Maybe we can encapsulate serialization, validation and functionality in a class with it's own Model and Form field. That would produce code like

expiration: RelativeTime = qualification.default_expiration_relative_time  # using a RelativeTimeModelField
grant.valid_to = expiration.apply_to(grant.valid_from)

[jeriox]

Hi @samuelson-ben, we had another discussion about your proposal.

* If we introduce a default expiration to the model it should be part of the Qualification form in a way that non technical people can easily understand how it works. I don't think that's the case here. We could provide some multipart widget that offers selection of different modes.

We decided that we want to offer a multipart widget for the user. This can be a very simple version in the first iteration. We thought about radio buttons distinguishing between "after x years" and "at x.y. after z years". This should cover the common usecases and can still be extended later. The data should be stored in a JSONField in the database in the form of {day: "1", month: "x", year: "+2"} where x is a placeholder and +2 means in two .

* model-wise, I'm not happy with having this complex datatype as a plain charfield with validator. Maybe we can encapsulate serialization, validation and functionality in a class with it's own Model and Form field. That would produce code like

For convenience, this should be offered by a custom formfield which we can also reuse in other situations (e.g. #209).

Would you feel comfortable implementing that or should we support you in that regard?

[samuelson-ben]

@jeriox @felixrindt sorry for not responding in the past.
Currently I am thinking: "Where does the work start and where ends it?"

I found some time and threw lines of code against my vm and got something like:

From Left to Right: Choice (Possibility for adding stuff), Days, Month, Years.

Currently I am storing the day month and year as integers in json (I hope).

I will fix some wrong texts and clean up some messes in my code (Sorry for every bit of bad quality you have to see in the code but this little integration of something is the biggest thing I have every done in Python). I hope I will get to it tomorrow and then I can present it to you.

Also I have to implement a way for giving a qualification date and calculation based on these values the expiration date.

[samuelson-ben]

I cleaned up a bit, provided translations and added the new json format to the qualification-fixtures.
Currently I am looking for a good way to implement a function which takes a start date and returns an end date (date of the qualification -> expiration date). I haven't found a good way until now. Do you have ideas (or should it be only be processed by the frontend)?

[samuelson-ben]

@felixrindt @jeriox
I am not quite sure how to handle the relative time.
My Plan was (esspecialy in a qualification submit plugin) that you can set the date when the user got the qualification and then ephios calculates the expiration time (so if it is a qualification submit, the submitting user can set the date of qualifying. In the user settings it could be a good thing to also have the ability to enter the date and the expiration date gets calculated.
I think saving the date of qualifing isn't a bad idea but the admin (or who every) should have the ability to set an expiration date that isn't the calculated.
Currently I am looking forward to implement a function to calculate the expiration time but I am unsure if it is good to calculate it in the backend especially if we implement it so every time you set the qualifying date to a new one the expiration time gets recalculated. But I am also unsure if it is a good idea of implementing it as javascript in the frontend. That's a decision I think you have to take.
Also I think however it will turn out I will need some help with it (I am new to Python and my Js is also unly functionable). Also for is the question in which directory or file to implement it logicaly.

[samuelson-ben]

Hi @felixrindt and @jeriox
currently I ran into one/two problems.
The DB Table for the request isn't generated directly.
The added field for the default expiration time in the qualification model is giving back an errormessage in the browser that I have to supply a valid JSON.
Is it possible that someone of you look over it?
(Also I thing I didn't implement Consequence... how it is ment to be).

[jeriox]

Hi @samuelson-ben, sorry for not replying for such a long time, we were both swamped with work.

I just took the time to look at your PR. A few comments:

• Your problems with the DB table are due to the fact that you did not tell Django to create migrations.
• The problem with the form telling you to supply valid JSON is due to a flaw in your serialization, you override the JSONField behaviour that stringifies the dict to be saved into the database.
• In general the code for the field is quite complicated and offers more flexibility than we need. We can support day, month and year as a fixed number of inputs, which should be enough for all usecases and simplifies the code drastically.
• You reimplemented a lot of features from Consequence (status with pending/approved, view to approve...) which we would prefer to handle via the existing consequence code.

I will prepare a PR against your branch with those suggestions. Thanks again for your work so far!

[jeriox]

@samuelson-ben my PR is ready, feel free to check it out and merge it into your branch. Happy to hear your thoughts on it