On Thu, 16 Jul 2020 at 10:44, sebb <seb...@gmail.com> wrote: > > 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.
Done > > 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 > >
