On Wed, 15 Jul 2020 at 22:54, Craig Russell <apache....@gmail.com> wrote: > > > > > On Jul 15, 2020, at 2:37 PM, sebb <seb...@gmail.com> wrote: > > > > On Wed, 15 Jul 2020 at 20:10, Craig Russell <apache....@gmail.com > > <mailto:apache....@gmail.com>> wrote: > >> > >> I'm now looking at how to integrate this with the workbench code. > >> > >> It looks like the front end does not need much work if all we do is add > >> one line to the index page for each emeritus request, and highlight the > >> requests that are ready for action. Some easy lifting is to have the front > >> end href: refer to the roster tool, but how to make this href create a > >> link to a new web page instead of using the existing page? If the user > >> chooses to use <command><click> to open the roster page in a new tab, it's > >> their choice but the default behavior should be to open a new page which > >> when closed will simply return to the workbench. > >> > >> The heavy lifting would be in the back end when preparing the headers for > >> transmission to the front end. This would possibly be in the > >> models/mailbox.rb client_headers function. For each emeritus request, add > >> an entry to the headers variable. > >> > >> Here's where it gets interesting: emeritus requests have nothing to do > >> with mailboxes. So how do we rationalize adding emeritus code to this > >> file? Where does the code that constructs an emeritus header belong? How > >> do we call it from the client_headers code? Perhaps something like: > >> > >> emeritus_headers = EmeritusFiles.client_headers > >> headers << emeritus_headers > >> > >> The EmeritusFiles.client_headers code needs to have some context for > >> credentials. > > > > The emeritus requests listing file now includes the epoch of the file, > > so there is no need for credentials. > > The documents directory in svn needs credentials for read access.
But not for determining the age, which is what I thought you wanted to calculate. > > > >> Where does Mailbox.client_headers get its own credentials? > >> > >> And I see that there is some new code to process emeritus-requests. How > >> does this code fit? > > > > Which code are you referring to? > > new f4222f6 Add epochs for emeritus request listings > > The new epoch code. There is now code to tell how old an emeritus request is. > > Were you going to integrate this into the workbench tool? What is the intent > of the new code? If you look at the committer display, it shows the age of any emeritus request. I thought that would be a useful start. I had not considered how to make use of it in the workbench. I think your idea of adding entries to the mail listing would be more convenient than having a separate page for it. > Thanks, > Craig > > > > >> Thanks, > >> Craig > >> > >>> On Jul 12, 2020, at 12:17 PM, Craig Russell <apache....@gmail.com> wrote: > >>> > >>> I'd like to discuss how to integrate secretary workbench with the roster > >>> emeritus process that now is in production. > >>> > >>> To recap: members who wish to go emeritus either > >>> > >>> - navigate to the documents site, download, print, sign, scan, and email > >>> an emeritus request to secretary or > >>> -navigate to roster __self__ page, double click Member status, and click > >>> (request emeritus status) or > >>> - send email to secretary stating that they no longer have access to > >>> foundation records and wish to go emeritus > >>> > >>> The above results in a file being placed in > >>> documents/emeritus-requests-received which pends for 10 days. > >>> > >>> After 10 days, secretary navigates to roster/memberid, verifies that > >>> there is a valid emeritus request, double clicks on Member status and > >>> clicks (move to emeritus). > >>> > >>> While the above is ok, it might be useful for secretary to be able easily > >>> to tell that there is an emeritus request pending. So I'm proposing a > >>> change to workbench. > >>> > >>> High level view: the index page, in addition to displaying incoming > >>> messages, also displays emeritus requests that are pending. The request > >>> could be formatted thus: > >>> Timestamp From Subject > >>> <date of request> Full Name of Member <date of 10 days later> > >>> > >>> The <date of request> would be a link to roster/memberid that would > >>> display a new page, not the workbench page. The request could be > >>> displayed the next time workbench is refreshed following receipt of the > >>> request, or could be displayed only after 10 days have elapsed. The > >>> message.status would indicate the "message" is an > >>> emeritus-request-not-ready-for-processing or > >>> emeritus-request-ready-for-processing with an appropriate visual cue. > >>> > >>> There is enough information available from svn to calculate the dates: > >>> %svn list --verbose emeritus-requests-received/clr.txt > >>> 56601 clr 4413 Jul 10 2020 clr.txt > >>> Timestamp From Subject > >>> Jul 10 2020 Craig L Russell emeritus rescission period ends Jul > >>> 20 2020 > >>> > >>> > >>> After secretary processes the request, closing the window would return to > >>> the secretary workbench. > >>> > >>> WDYT? > >>> > >>> Craig L Russell > >>> c...@apache.org <mailto:c...@apache.org> <mailto:c...@apache.org > >>> <mailto:c...@apache.org>> > >>> > >> > >> Craig L Russell > >> c...@apache.org <mailto:c...@apache.org> > Craig L Russell > c...@apache.org >
