[rfc][icedtea-web] PolicyEditor gains a real parser

Jiri Vanek jvanek at redhat.com
Thu Apr 30 11:49:54 UTC 2015

On 04/30/2015 12:27 AM, Andrew Azores wrote:
> Hi,
> ----- Original Message -----
>> ----- Original Message -----
>>> On 03/18/2015 06:12 PM, Andrew Azores wrote:
>>>> ----- Original Message -----
>>>>> On 03/14/2015 09:19 PM, Andrew Azores wrote:
>>>>>> Hi,
>>>>>> Attached is an updated version of this patch, which makes the editor
>>>>>> GUI
>>>>>> display the actual PolicyIdentifiers, rather than just codebases.
>>>>>> Nothing
>>>>>> else has changed since the previous version (other than also updating
>>>>>> the
>>>>>> patch to apply cleanly on current HEAD), but I think that this patch is
>>>>>> in
>>>>>> a pretty good state right now, and I'd like to push it and continue
>>>>>> working on it in further, smaller changesets. My next goals are to
>>>>>> adapt
>>>>>> the UI to allow modification of the signedBy and principals for each
>>>>>> identifier, and then to introduce an "Advanced View" toggle of some
>>>>>> sort
>>>>>> which will toggle between the existing codebase-oriented simplified UI,
>>>>>> and the full UI which I just outlined. After that, I will look at
>>>>>> refactoring it all to use a single class as the point of contact with
>>>>>> the
>>>>>> sun classes, as I've already discovered earlier today that this
>>>>>> changeset
>>>>>> no longer builds with the latest JDK 8.
>>>>> Just quick galnce - I'm against removal of ciodebase:((( I know it is
>>>>> hard,
>>>>> but some replcament
>>>>> hsould be deffined.
>>>> For now I've put it back then. I think eventually flags for SignedBy and
>>>> Principals should be added as well, and the three of
>>> That sounds good.
>>>> them can then be used to create a selector. I don't really like the idea
>>>> that using just -codebase alone for example would result
>>>   > in selecting everything that has a matching codebase - I think it's
>>>   > better
>>>   > if in that situation, it's assumed that you want
>>> hmhm. yes.
>>>   > that matching codebase, and the default (empty/null) for other
>>>   > nonspecified criteria. It makes more sense that way since using
>>>   >  the flags this way can either create a new entry or select an existing
>>>   >  match.
>>> agree
>>>>> Also - I owuld like to release in month,  or two - no longer. How is
>>>>> your
>>>>> work on this suitbale with
>>>>> this schedule?
>>>>> J.
>>>> My final exams start in about three weeks and run until the end of April,
>>>> so I don't know how much time I will have during that period. Can you
>>>> define what more work you want to be present in the next release and what
>>>> work can wait until after?
>>> My issue is, that 1.6 seems pretty stable right now. And this is a big
>>> patch.
>>> So questions are - How stable and useful is this patch as it is alone?
>>> If it is worthy to make it to 1.6?
>>> What re risks that you will not be able
>>> to tune it before release?
>> Very high.
>>> also I wonted to write to translators, that  they can start transalting -
>>> will some upcoming work  bring changes to properties?
>> There would probably be some more new messages added as the remaining issues
>> with the UI here are worked through.
>>> if answers are
>>> "not sure" "maybe" "maybe not" and "yes" then I would vote for suspending
>>> to
>>> 1.7.
>>> hmm?
>>> J.
>>>> Thanks,
>>>> Andrew
>> The last several weeks were much more busy with school than anticipated - all
>> of the final assignments and projects turned out to be quite major and time
>> consuming, and there's still one last one that I have to hammer out for next
>> week, and then I have final exams to worry about. That along with some
>> family medical issues in the past few weeks has left me with no time to
>> continue working on this patch so far. I'm not going to drop this patch but
>> I'm going to have to put it on hold for a few weeks, I think. So I
>> definitely vote for it to be suspended until 1.7 as well.
>> Thanks,
>> Andrew
> Just in time for my part-time contract ending, I have this patch back up for review. Since last time the PolicyEditor has completely transitioned from using the "codebase" as its identifier for policy entries to using the actual PolicyIdentifier type, including UI updates to display AND modify the SignedBy and Principals elements. The work is still mostly plumbing - not all that much really had to change for the UI, it's mostly just small additions (more dialogs, menu items, etc.).
> You can also use -codebase, -signedby, and -principals from the command line to form a "selector", which will create a new PolicyIdentifier with the given criteria, create it if needed, and select it when the PolicyEditor appears - much like the old behaviour when only -codebase existed. I also fixed a bug where the -file switch didn't work properly, and a bug where adding custom permissions would fail if the given PolicyIdentifier had not yet been created (eg by defining standard permissions for it first).
> There still isn't an advanced vs simple view, but that's a lot of extra work that I think should be done after this patch has finally been merged. It's already quite a large patch.

This is cool stuff!

I like the ideas inside. however...

Several issues with user experience popped up which should be fixed:

When you start jsut prefix/bin/policyeditor with no args, then it immediately complains about :can 
not open file"
  - imho it should not complain:)
   I see two possibilities - open default file (but it may be tricky), or work on no file, and then 
inform (it was like that, wasn't it? I'm for this one...)

when you open "no file" then save as(or open file later ) then saving is popuping many errors.. and 
file seems to not be saved

opening of default file seems to be doing noting (or the app is saving the file  strangly)

save is broken "the file was not on disk, creating new" -> saved -> :error during saving" Some save 
dialogue missing perhaps??

(whole this saving/laoding seems to be completly broken - you can open file but hte content do not 
repalce and so on... Also is this changeset counting with "open default file" afaik not)

escape button (and cross in dialogue)  from that dialogue with codebasese/principals/signedby... is 
annoying with forcing to fill something in. Afaik The cross/ecape button should be related to 
cancel. Not ok :)

I can see you have added modify codebas/signed/principals as three separate menu entries. its good 
and +1 for keeping it. But what about general "modify?  Also hitting "remove" is pretty simple... 
One may regret hitting it by accident. As the " 'add new' dialogue" is the only good viwer - then 
what about this : instead of "remove" put "view" button here, which allwos general modification 
and/or removal.

the to string used in list is nasty :) I think it can safel ignore (notshow) unspeciffied fields.
so policy without principals and with null signedBy will show only  codeabase.  and so on.. Jsut 
dont show unspecified.

Al above seems serious enough to be fixed before push.

Maybe "view filter" - "clever" "all" "selected" + checkboxes like codebase/principals/signed by - 
but this can go as another changeset

Maybe also the "general modify button" can go as another changeset.

One question - how it behaves/should behave when only one (or two)  from codebase signedby 
principals are specified?

I was not able to try it, because I was not able to save/load my changes (related to above)
   in case of selection I'm probably for "choose first matching"
   in case of creating new one - it is pretty clear.
      Teh issue is rising, when some partially amtching is already found. Then it should update it?

Now - when run in sandbox is used - only codebase is sent to policy editor - isnt better to sent 
also prinsipals and signed by? afaik you know them both in this time...

Also I think run in sandbox is now broken, because applications which depends on reflection, but 
were working in sadnbox (with reflection on - like geogebra) now dont work.

Hoping to see this in soon, but as it is, is broken


More information about the distro-pkg-dev mailing list