> 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.
> 
>> 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?

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

Reply via email to