Development
Major changes in feedback, see commit messages.
Master branch needs to be merged into development first(?)
I have no rights for that either. So, it would be nice if one of you did that.
I'd like to work with this in addition to the submission class to develop a way to use the feedback user interface with jupyters services.
Right now everything should be working fine with email, if used like shown in misc example notebook.
Merge request reports
Activity
219 else: 220 user_name = os.environ['HOSTNAME'] # take hostname as fall-back 221 self.entry['userhash'] = hashlib.sha256(str.encode(user_name)).hexdigest() 222 self.entry['answer'] = {key: w.value for key, w in self.widgets_container.items()} 223 self.entry['status'] = 'saved_locally' 224 225 # confirm submission if not happened already 226 if not self.is_send_confirmed: 227 self.btn_submit.description = self.feedback_text['confirm_send'] 228 self.btn_submit.layout.width = 'auto' 229 self.is_send_confirmed = True 230 return 231 232 # dump entries into json file 233 # append only if not entry does not already exist in json file 234 # TODO - Editing locally saved submission is not possible. Change? Current status of feedback submission:
Locally saved entries can be changed by editing the feedback.json manually.
Also mail_sent attribute can manually be reset to saved_locally by anyone, allowing to resend multiple feedbacks. Further, removing the file causes the feedback to reset and everything is possible again, including resending submission.
Without editing or removing the file neither changing locally saved submission nor sending multiple mails is possible.
In the short run, the file can be hidden, so it would be harder for anyone to edit or remove at all.
This would be done platform specific:
On Windows: set file attribute to hidden.
On MacOS/Linux: put a dot in front of the filename.
In the long run though, knowing what can be done with JupyterHub services would be essential.Edited by Hafiz Emin Kosar
293 295 294 296 Dumps self.entries into existing file 295 297 """ 296 with open(self.feedback_path, mode='w', encoding='utf-8') as f: 298 with open(self.feedback_path, mode='r+', encoding='utf-8') as f: Ok, thanks @hafiz.emin.kosar ! So, should I merge master into development and you keep going or should I merge development into master (as the merge request suggests) and you get a new feature branch. This is dependent on how important these changes here are to master.
mentioned in commit 1851f5b0
Okay thanks!
I realized that I made a mistake by checking 'Squash commits when merge request is accepted' in the merge request.
Now all commits are squashed into the last commit, which in my opinion does not look very good and corrupts the commit history.
More info on that: https://git.rwth-aachen.de/help/user/project/merge_requests/squash_and_merge
Is there a way to 'unsquash' the commits? (Maybe revert and merge again without the checked option?)