[Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer

[Walter Bender]

On Sun, Aug 12, 2012 at 8:48 PM, Gary Martin <garycmartin at googlemail.com> wrote:
> Hi Anish,
>
> I've uploaded a mockup image to the wiki [1] which covers most of the items raised in this thread:
>
>  - a new security section (that should only be shown if there is lease information)
>  - lease number of days remaining
>  - lease absolute expiry date (date string should use correct formatting to display locale date format)
>
> Did I miss anything?

One nit: There is no such thing as Sugar Labs Inc. Should be: Sugar
Labs, a member project of the Software Freedom Conservancy.

regards.

-walter
>
> Regards,
> --Gary
>
> [1] http://wiki.sugarlabs.org/go/File:Settings_About_My_Computer_Security_Section_Mockup.png
>
> On 7 Aug 2012, at 17:55, Anish Mangal <anish at activitycentral.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Daniel,
>>
>> Thanks for replying!
>>
>> On Tuesday 07 August 2012 10:12 PM, Daniel Drake wrote:
>>> On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal
>>> <anish at activitycentral.com> wrote:
>>>> One problem they were also trying to get around in Paraguay is
>>>> that during vacations, the kids don't go to the schools and hence
>>>> the leases expire. If the kids also know about this information,
>>>> then they can easily make sure that they don't get 'locked out'
>>>
>>> You'd hope that the project would make provisions for long-enough
>>> leases to be supplied before the vacations. But I can see the use
>>> for this for when that doesn't happen (which is understandable
>>> given high workloads and so on).
>>>
>>> Talking more with the team in Nicaragua, this functionality would
>>> be useful for them too. Similar situations are occuring here where
>>> laptops were activated for a certain amount of time, with the
>>> strong expectation that internet connectivity would become
>>> available in the schools before the activations expire (so that
>>> they can be automatically updated/renewed). These expectations look
>>> like they won't turn out to be true :(
>>>
>>> So a manual activation update process will happen and the ability
>>> for someone less-technical to be able to quickly check whether this
>>> manual update process has completed OK would be of value (that
>>> would be the person's only contact with activations - we aren't
>>> expecting them to be able to solve any problems if the results are
>>> bad, other than report up the chain).
>>>
>>
>> This is exactly the kind of clear info that should have been in the
>> feature page in the first place. Sorry for not doing it earlier.
>>
>>> Anyway, the use cases you describe in your mail don't seem to be
>>> described on the feature page. Could you please extend the feature
>>> page to go into more detail about this? I'll then add the above
>>> local case if its of interest.
>>>
>>
>> +1
>>
>>>
>>> Why is the proposal to show the number of days remaining?
>>>
>>
>> Yes, I remember discussing specifically this with Roberto (PyEduca
>> Technical head) back in Dec 2010, and my suggestion was exactly the
>> same (to display the date).
>>
>> However, as per them (and I know this is not a rational explanation),
>> they wanted us to display "no of days remaining".
>>
>>> The Nicaraguan team have expressed a strong preference that this
>>> should (instead, or additionally) display the expiry date. When
>>> dealing with long duration activations, which is often the case
>>> (until good connectivity is established), having a teacher phone up
>>> and say "there are 137 days remaining" (and then having to
>>> calculate the day of expiry in order to put an appropriately timed
>>> school visit on the calendar) would be a pain.
>>>
>>
>> I agree with this, and since I cannot seem to remember exactly why
>> they wanted it to display in terms of no. of days remaining, I'll ping
>> them or we can go with this.
>>
>>>> Since this feature is only relevant for the XO at the moment,
>>>> making use of the bitfrost API would be acceptable to me, but I
>>>> don't see a lot wrong here by parsing the lease.sig directly.
>>>> This file is supposed to be automatically generated/updated in
>>>> normal use cases.
>>>
>>> Are you planning to parse sig02 (delegated leases) "by hand" as
>>> well? What if the lease is corrupt in some way?
>>>
>>> I can see myself objecting to any implementation of this that
>>> doesn't reuse bitfrost. It takes care of all of the corner cases
>>> and will avoid code duplication.
>>>
>>
>> Again, it seemed to solve the use case we had in Paraguay, and the
>> idea behind upstreaming a feature is that it goes through this process
>> of review. I am up for changing the code to use the bitfrost api. It
>> should not be complex (if it's adequately documented somewhere).
>>
>>> Daniel _______________________________________________ Sugar-devel
>>> mailing list Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>>
>> - --
>> Anish Mangal
>> Dextrose Project Manager
>> Activity Central
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJQIUh6AAoJEBoxUdDHDZVpEX8H/j5oCzGUvnfIWdy1f/awAnkf
>> Trtsm4Me8r2D0ufxEyIZkUHugCQPUTdPqDEAlexr8ziQjy8mqNLrbvEWwwxxl4ho
>> XstY7RZsk9gPGVYiE1bLniIZnO5e63lIyBEkM3eNgkHrO8XTPw86lBBcTcx9XDrx
>> T00HW8J1UGDMo29SRcrnxnNVd6j+uArJXcaeSXhLAPb3xkaharF22AbTlWgQ+4s5
>> YIzvIfmEYMpqXbCCY+IPSVxzcpdRuHhueaFKchDfzRm01Wf77laACUg6+ZFkq/Ft
>> 9ChV1LNekysQwf+yCZ9dB9HZdfIjjJ4m1WjrPhrQtqruevs9/nglTp2djqsPU00=
>> =QHV1
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org