On Wed, 15 Jul 2020 at 20:10, Craig Russell <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. > 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? > 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> > > > > Craig L Russell > c...@apache.org >
