You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Craig Russell <ap...@gmail.com> on 2020/07/12 19:17:47 UTC
Secretary workbench processes emeritus requests
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
clr@apache.org
Re: Secretary workbench processes emeritus requests
Posted by sebb <se...@gmail.com>.
On Thu, 16 Jul 2020 at 10:44, sebb <se...@gmail.com> wrote:
>
> On Wed, 15 Jul 2020 at 22:54, Craig Russell <ap...@gmail.com> wrote:
> >
> >
> >
> > > On Jul 15, 2020, at 2:37 PM, sebb <se...@gmail.com> wrote:
> > >
> > > On Wed, 15 Jul 2020 at 20:10, Craig Russell <apache.clr@gmail.com <ma...@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 <ap...@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
> > >>> clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>>
> > >>>
> > >>
> > >> Craig L Russell
> > >> clr@apache.org <ma...@apache.org>
> > Craig L Russell
> > clr@apache.org
> >
Re: Secretary workbench processes emeritus requests
Posted by sebb <se...@gmail.com>.
On Wed, 15 Jul 2020 at 22:54, Craig Russell <ap...@gmail.com> wrote:
>
>
>
> > On Jul 15, 2020, at 2:37 PM, sebb <se...@gmail.com> wrote:
> >
> > On Wed, 15 Jul 2020 at 20:10, Craig Russell <apache.clr@gmail.com <ma...@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 <ap...@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
> >>> clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>>
> >>>
> >>
> >> Craig L Russell
> >> clr@apache.org <ma...@apache.org>
> Craig L Russell
> clr@apache.org
>
Re: Secretary workbench processes emeritus requests
Posted by Craig Russell <ap...@gmail.com>.
> On Jul 15, 2020, at 2:37 PM, sebb <se...@gmail.com> wrote:
>
> On Wed, 15 Jul 2020 at 20:10, Craig Russell <apache.clr@gmail.com <ma...@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 <ap...@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
>>> clr@apache.org <ma...@apache.org> <mailto:clr@apache.org <ma...@apache.org>>
>>>
>>
>> Craig L Russell
>> clr@apache.org <ma...@apache.org>
Craig L Russell
clr@apache.org
Re: Secretary workbench processes emeritus requests
Posted by sebb <se...@gmail.com>.
On Wed, 15 Jul 2020 at 20:10, Craig Russell <ap...@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 <ap...@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
> > clr@apache.org <ma...@apache.org>
> >
>
> Craig L Russell
> clr@apache.org
>
Re: Secretary workbench processes emeritus requests
Posted by Craig Russell <ap...@gmail.com>.
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. 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?
Thanks,
Craig
> On Jul 12, 2020, at 12:17 PM, Craig Russell <ap...@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
> clr@apache.org <ma...@apache.org>
>
Craig L Russell
clr@apache.org
Re: Secretary workbench processes emeritus requests
Posted by Matt Sicker <bo...@gmail.com>.
Sounds reasonable so far to me from a UI standpoint.
On Sun, Jul 12, 2020 at 14:17 Craig Russell <ap...@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
> clr@apache.org
>
> --
Matt Sicker <bo...@gmail.com>