Mailing List Archive: Bricolage: devel

Keywords Permissions

Index | Next | Previous | View Threaded

adrian at gossamer-threads

Feb 25, 2009, 3:26 PM

Post #1 of 22 (4172 views)
Permalink

Keywords Permissions

Hi,

I don't think this is something that's ready to commit as is (as I don't
think it's implemented completely), but Alex thought it might be useful
for others on the list.

Bricolage already has support for groups for keywords. However, the
group support only applies to the Keywords manager (Admin => System =>
Publishing => Keywords).

The attached patch enforces the group permissions for adding new
keywords to stories, categories and media.

Remember to set up the group permissions first:
1) Admin => System => Groups => Add a New Group
2) Set Name to something like "Keyword Editors" and set Group Type to
"User Group"
3) Click on Permissions
4) Select "Object Groups" Permission Type
5) For "All Keywords", change the permission to "Create", and click Save
6) Add members to the group and click Save

Now, when a user who isn't in the Keyword Editors group tries to add a
new keyword to a story, they get an error. They will still be able to
add keywords to a story that already exist.

The reason I don't think it's complete is that I think users should have
read access to even add keywords that are already in the database. Not
really a big change, but I'm sure there are some other quirks with how
the permissions work that would need to be ironed out before it would be
a commitable change.

Adrian

Attachments:

keyword_perms.patch (2.16 KB)

adrian at gossamer-threads

Feb 25, 2009, 3:34 PM

Post #2 of 22 (4075 views)
Permalink

Re: Keywords Permissions [In reply to]

Just a minor style adjustment to the last patch.

Adrian

Adrian Yee wrote:
> Hi,
>
> I don't think this is something that's ready to commit as is (as I don't
> think it's implemented completely), but Alex thought it might be useful
> for others on the list.
>
> Bricolage already has support for groups for keywords. However, the
> group support only applies to the Keywords manager (Admin => System =>
> Publishing => Keywords).
>
> The attached patch enforces the group permissions for adding new
> keywords to stories, categories and media.
>
> Remember to set up the group permissions first:
> 1) Admin => System => Groups => Add a New Group
> 2) Set Name to something like "Keyword Editors" and set Group Type to
> "User Group"
> 3) Click on Permissions
> 4) Select "Object Groups" Permission Type
> 5) For "All Keywords", change the permission to "Create", and click Save
> 6) Add members to the group and click Save
>
> Now, when a user who isn't in the Keyword Editors group tries to add a
> new keyword to a story, they get an error. They will still be able to
> add keywords to a story that already exist.
>
> The reason I don't think it's complete is that I think users should have
> read access to even add keywords that are already in the database. Not
> really a big change, but I'm sure there are some other quirks with how
> the permissions work that would need to be ironed out before it would be
> a commitable change.
>
> Adrian
>

Attachments:

keyword_perms.patch (2.05 KB)

alex at gossamer-threads

Feb 25, 2009, 4:23 PM

Post #3 of 22 (4069 views)
Permalink

Re: Keywords Permissions [In reply to]

Hi,

> I don't think this is something that's ready to commit as is (as I don't
> think it's implemented completely), but Alex thought it might be useful
> for others on the list.

Just to expand on this, I do think this would be good in trunk. If
you've seen a keyword or "tags" list managed by a large number of people
over time, it can get pretty crazy. The ajax add will help avoid
duplication, but if you have a fixed taxonomy, it would be nice to be
able to limit the ability of editors to add new keywords, but rather
force them to use existing ones.

Cheers,

Alex

--
Alex Krohn <alex [at] gossamer-threads>

david at kineticode

Feb 26, 2009, 9:02 AM

Post #4 of 22 (4061 views)
Permalink

Re: Keywords Permissions [In reply to]

On Feb 25, 2009, at 3:26 PM, Adrian Yee wrote:

> The reason I don't think it's complete is that I think users should
> have read access to even add keywords that are already in the
> database. Not really a big change, but I'm sure there are some
> other quirks with how the permissions work that would need to be
> ironed out before it would be a commitable change.

Hrm. Why? If I grant READ access to All Users on the All Keywords
group, it covers that case, no?

> - $kw = Bric::Biz::Keyword->new({ name => $_ })->save;
> + $kw = Bric::Biz::Keyword->new({ name => $_ });
> + if (chk_authz($kw, CREATE)) {
> + $kw->save;
> + }

You don't have to construct the keyword before creating it. IIRC, You
can just do:

$kw = Bric::Biz::Keyword->new({ name => $_ })->save
if authz('Bric::Biz::Keyword', CREATE );

Are permissions already checked in the keyword profile?

Best,

David

adrian at gossamer-threads

Feb 26, 2009, 12:16 PM

Post #5 of 22 (4065 views)
Permalink

Re: Keywords Permissions [In reply to]

David E. Wheeler wrote:
> On Feb 25, 2009, at 3:26 PM, Adrian Yee wrote:
>
>> The reason I don't think it's complete is that I think users should
>> have read access to even add keywords that are already in the
>> database. Not really a big change, but I'm sure there are some other
>> quirks with how the permissions work that would need to be ironed out
>> before it would be a commitable change.
>
> Hrm. Why? If I grant READ access to All Users on the All Keywords group,
> it covers that case, no?

Sure, but my point is that when we're adding keywords to a story, it
currently doesn't perform a check. My patch only makes the check when
we're creating a new keyword.

Easy enough to do I guess. The code from
App::Callback::Profile::Story::_handle_keywords:

foreach (@{ mk_aref($param->{new_keyword}) }) {
next unless $_;
my $kw = Bric::Biz::Keyword->lookup({ name => $_ });
unless ($kw) {
$kw = Bric::Biz::Keyword->new({ name => $_ });
$kw->save if chk_authz($kw, CREATE);
log_event('keyword_new', $kw);
}
push @$new, $kw;
}
$story->add_keywords(@$new) if $new;

Just stick another check for READ perms after the lookup (if we have a
keyword) and that should do it. What about deletes? Should there be
any permissions checking on deleting a keyword from a
story/media/category? I guess you're not really changing a keyword, so
that's out of the scope of keyword permissions.

>> - $kw = Bric::Biz::Keyword->new({ name => $_ })->save;
>> + $kw = Bric::Biz::Keyword->new({ name => $_ });
>> + if (chk_authz($kw, CREATE)) {
>> + $kw->save;
>> + }
>
> You don't have to construct the keyword before creating it. IIRC, You
> can just do:
>
> $kw = Bric::Biz::Keyword->new({ name => $_ })->save
> if authz('Bric::Biz::Keyword', CREATE );

The nice thing about using the created keyword object is that you get a
nicer error:

You have not been granted access to the �foo bar� Keyword

instead of:

You have not been granted access to the �� Keyword

But perhaps we should be returning a less cryptic error?

> Are permissions already checked in the keyword profile?

Yep. Assuming by keyword profile, you're referring to the Admin =>
Publishing => Keywords interface (sorry, I'm not up on the Bricolage
lingo yet).

Adrian

david at kineticode

Feb 26, 2009, 12:42 PM

Post #6 of 22 (4062 views)
Permalink

Re: Keywords Permissions [In reply to]

On Feb 26, 2009, at 12:16 PM, Adrian Yee wrote:

> David E. Wheeler wrote:
>> On Feb 25, 2009, at 3:26 PM, Adrian Yee wrote:
>>> The reason I don't think it's complete is that I think users
>>> should have read access to even add keywords that are already in
>>> the database. Not really a big change, but I'm sure there are
>>> some other quirks with how the permissions work that would need to
>>> be ironed out before it would be a commitable change.
>> Hrm. Why? If I grant READ access to All Users on the All Keywords
>> group, it covers that case, no?
>
> Sure, but my point is that when we're adding keywords to a story, it
> currently doesn't perform a check. My patch only makes the check
> when we're creating a new keyword.

Well, if it's in a story, they should be able to see it's part of the
story, and even delete it, if they have EDIT permission to the story.
That's how it works with Elements and Categories.

> Just stick another check for READ perms after the lookup (if we have
> a keyword) and that should do it.

If they're creating it, I don't see the point of that. I'm probably
just missing something, though.

> What about deletes? Should there be any permissions checking on
> deleting a keyword from a story/media/category? I guess you're not
> really changing a keyword, so that's out of the scope of keyword
> permissions.

Correct. Right now, if you're editing a story, you can edit or delete
any of the categories or elements associated with that story, even if
you don't have READ access to the underlying element types or
categories. That might be something to change at some point, but it's
a separate issue. You're just bringing keyword association into
alignment with element and category association.

Oh, but you should probably disable the inputs for adding keywords if
users don't have permission to create keywords, FWIW. That way it
shouldn't really even get to the point where you're checking the
permission now (though you still should, of course).

Also, the same checks should be put into the SOAP interface, for
consistency.

> The nice thing about using the created keyword object is that you
> get a nicer error:
>
> You have not been granted access to the �foo bar� Keyword
>
> instead of:
>
> You have not been granted access to the �� Keyword
>
> But perhaps we should be returning a less cryptic error?

Yes. If it's a CREATE error, it should be "You have not been granted
permission to create keywords." Or something like that.

>> Are permissions already checked in the keyword profile?
>
> Yep. Assuming by keyword profile, you're referring to the Admin =>
> Publishing => Keywords interface (sorry, I'm not up on the Bricolage
> lingo yet).

Yes, exactly (/admin/profile/keyword is the URI, IIRC).

Best,

David

adrian at gossamer-threads

Feb 26, 2009, 1:02 PM

Post #7 of 22 (4056 views)
Permalink

Re: Keywords Permissions [In reply to]

>> Just stick another check for READ perms after the lookup (if we have a
>> keyword) and that should do it.
>
> If they're creating it, I don't see the point of that. I'm probably just
> missing something, though.

If a user is adding keywords to a story, then either they're creating a
new keyword (in which we check if they have CREATE perms), or they're
using an existing keyword. In the second case I think they should have
READ permission to the keywords, should they not?

> Oh, but you should probably disable the inputs for adding keywords if
> users don't have permission to create keywords, FWIW. That way it
> shouldn't really even get to the point where you're checking the
> permission now (though you still should, of course).

Well, not having permission to create keywords doesn't necessarily mean
they still can't add existing keywords to a story. That's where I think
the READ permission comes into play.

> Also, the same checks should be put into the SOAP interface, for
> consistency.

Haven't looked into this, but will when I get a chance.

>> But perhaps we should be returning a less cryptic error?
>
> Yes. If it's a CREATE error, it should be "You have not been granted
> permission to create keywords." Or something like that.

I'll have to look into how Bricolage handles language and throwing errors.

Adrian

david at kineticode

Feb 26, 2009, 2:03 PM

Post #8 of 22 (4056 views)
Permalink

Re: Keywords Permissions [In reply to]

On Feb 26, 2009, at 1:02 PM, Adrian Yee wrote:

>> If they're creating it, I don't see the point of that. I'm probably
>> just missing something, though.
>
> If a user is adding keywords to a story, then either they're
> creating a new keyword (in which we check if they have CREATE
> perms), or they're using an existing keyword. In the second case I
> think they should have READ permission to the keywords, should they
> not?

Oh, yes, duh. Sorry, was being dense.

>> Oh, but you should probably disable the inputs for adding keywords
>> if users don't have permission to create keywords, FWIW. That way
>> it shouldn't really even get to the point where you're checking the
>> permission now (though you still should, of course).
>
> Well, not having permission to create keywords doesn't necessarily
> mean they still can't add existing keywords to a story. That's
> where I think the READ permission comes into play.

You are correct.

>> Also, the same checks should be put into the SOAP interface, for
>> consistency.
>
> Haven't looked into this, but will when I get a chance.

It'll be pretty similar.

>>> But perhaps we should be returning a less cryptic error?
>> Yes. If it's a CREATE error, it should be "You have not been
>> granted permission to create keywords." Or something like that.
>
> I'll have to look into how Bricolage handles language and throwing
> errors.

See Bric::Util::Lang and subclasses.

Best,

David

adrian at gossamer-threads

Feb 27, 2009, 7:10 PM

Post #9 of 22 (4047 views)
Permalink

Re: Keywords Permissions [In reply to]

Okay, the attached patch does the extra READ permission check and
returns proper error messages.

Adrian

David E. Wheeler wrote:
> On Feb 26, 2009, at 1:02 PM, Adrian Yee wrote:
>
>>> If they're creating it, I don't see the point of that. I'm probably
>>> just missing something, though.
>>
>> If a user is adding keywords to a story, then either they're creating
>> a new keyword (in which we check if they have CREATE perms), or
>> they're using an existing keyword. In the second case I think they
>> should have READ permission to the keywords, should they not?
>
> Oh, yes, duh. Sorry, was being dense.
>
>>> Oh, but you should probably disable the inputs for adding keywords if
>>> users don't have permission to create keywords, FWIW. That way it
>>> shouldn't really even get to the point where you're checking the
>>> permission now (though you still should, of course).
>>
>> Well, not having permission to create keywords doesn't necessarily
>> mean they still can't add existing keywords to a story. That's where
>> I think the READ permission comes into play.
>
> You are correct.
>
>>> Also, the same checks should be put into the SOAP interface, for
>>> consistency.
>>
>> Haven't looked into this, but will when I get a chance.
>
> It'll be pretty similar.
>
>>>> But perhaps we should be returning a less cryptic error?
>>> Yes. If it's a CREATE error, it should be "You have not been granted
>>> permission to create keywords." Or something like that.
>>
>> I'll have to look into how Bricolage handles language and throwing
>> errors.
>
> See Bric::Util::Lang and subclasses.
>
> Best,
>
> David
>
>

Attachments:

keyword_perms.patch (4.89 KB)

david at kineticode

Feb 27, 2009, 9:24 PM

Post #10 of 22 (4051 views)
Permalink

Re: Keywords Permissions [In reply to]

On Feb 27, 2009, at 7:10 PM, Adrian Yee wrote:

> Okay, the attached patch does the extra READ permission check and
> returns proper error messages.

Looks good. I request three more things, however:

1. Please do not use tabs in code. Use four spaces instead. See
Bric::Hacker for Emacs and Vim configuration to make this easy.

2. Would you please also disable the keyword adding field in the UI
when the user does not have READ access to keywords.

3. If the error messages you've written don't exist in the language
files already, will you add them to the end of each? You only need to
worry about those files, like de_de.pm, where there is already a long
section of commented-out messages that need translating. You can just
add them to the end of the list.

With these tweaks, I think that this code is ready for prime time! Oh,
we'll also need the Changes file updated, and probably also
Bric::Changes and comp/help/patchers.html. :-)

Thanks!

David

adrian at gossamer-threads

Mar 2, 2009, 10:32 AM

Post #11 of 22 (4028 views)
Permalink

Re: Keywords Permissions [In reply to]

> 1. Please do not use tabs in code. Use four spaces instead. See
> Bric::Hacker for Emacs and Vim configuration to make this easy.

I don't use tabs? Not sure where you're seeing tabs.

> 2. Would you please also disable the keyword adding field in the UI when
> the user does not have READ access to keywords.

Oops, forgot about that. I now have it so that if you don't have READ
access to keywords, but there are keywords associated with the story,
then the keywords section still shows up, but the add field is hidden.

> 3. If the error messages you've written don't exist in the language
> files already, will you add them to the end of each? You only need to
> worry about those files, like de_de.pm, where there is already a long
> section of commented-out messages that need translating. You can just
> add them to the end of the list.

Done.

I also added permission checking for the SOAP code. However, I haven't
played around with the SOAP stuff, so I haven't tested it other than it
compiling.

Adrian

Attachments:

keyword_perms.patch (19.6 KB)

adrian at gossamer-threads

Mar 2, 2009, 11:12 AM

Post #12 of 22 (4023 views)
Permalink

Re: Keywords Permissions [In reply to]

I forgot to ask about something I noticed while working on the keywords
code.

In comp/widgets/story_prof/edit_meta.html, in the keywords section,
there's some code that generates a list of categories if
ENABLE_CATEGORY_BROWSER is enabled. I don't see how this is related to
the keywords. A bit of legacy code?

Not a big deal, just seemed a little odd is all.

Adrian

Adrian Yee wrote:
>> 1. Please do not use tabs in code. Use four spaces instead. See
>> Bric::Hacker for Emacs and Vim configuration to make this easy.
>
> I don't use tabs? Not sure where you're seeing tabs.
>
>> 2. Would you please also disable the keyword adding field in the UI
>> when the user does not have READ access to keywords.
>
> Oops, forgot about that. I now have it so that if you don't have READ
> access to keywords, but there are keywords associated with the story,
> then the keywords section still shows up, but the add field is hidden.
>
>> 3. If the error messages you've written don't exist in the language
>> files already, will you add them to the end of each? You only need to
>> worry about those files, like de_de.pm, where there is already a long
>> section of commented-out messages that need translating. You can just
>> add them to the end of the list.
>
> Done.
>
> I also added permission checking for the SOAP code. However, I haven't
> played around with the SOAP stuff, so I haven't tested it other than it
> compiling.
>
> Adrian
>

david at kineticode

Mar 2, 2009, 12:13 PM

Post #13 of 22 (4027 views)
Permalink

Re: Keywords Permissions [In reply to]

On Mar 2, 2009, at 10:32 AM, Adrian Yee wrote:

>> 1. Please do not use tabs in code. Use four spaces instead. See
>> Bric::Hacker for Emacs and Vim configuration to make this easy.
>
> I don't use tabs? Not sure where you're seeing tabs.

Oh, maybe you don't. I just saw that the indentation was off in a few
places.

>> 2. Would you please also disable the keyword adding field in the UI
>> when the user does not have READ access to keywords.
>
> Oops, forgot about that. I now have it so that if you don't have
> READ access to keywords, but there are keywords associated with the
> story, then the keywords section still shows up, but the add field
> is hidden.

Perfect.

>> 3. If the error messages you've written don't exist in the language
>> files already, will you add them to the end of each? You only need
>> to worry about those files, like de_de.pm, where there is already a
>> long section of commented-out messages that need translating. You
>> can just add them to the end of the list.
>
> Done.

Thanks.

> I also added permission checking for the SOAP code. However, I
> haven't played around with the SOAP stuff, so I haven't tested it
> other than it compiling.

It's probably fine; I'll try to get this reviews in the next day or two.

On Mar 2, 2009, at 11:12 AM, Adrian Yee wrote:

> I forgot to ask about something I noticed while working on the
> keywords code.
>
> In comp/widgets/story_prof/edit_meta.html, in the keywords section,
> there's some code that generates a list of categories if
> ENABLE_CATEGORY_BROWSER is enabled. I don't see how this is related
> to the keywords. A bit of legacy code?
>
> Not a big deal, just seemed a little odd is all.

Probably, but I'm not seeing it. Can you paste in what you're talking
about?

Thanks,

David

adrian at gossamer-threads

Mar 2, 2009, 12:23 PM

Post #14 of 22 (4029 views)
Permalink

Re: Keywords Permissions [In reply to]

>> I forgot to ask about something I noticed while working on the
>> keywords code.
>>
>> In comp/widgets/story_prof/edit_meta.html, in the keywords section,
>> there's some code that generates a list of categories if
>> ENABLE_CATEGORY_BROWSER is enabled. I don't see how this is related
>> to the keywords. A bit of legacy code?
>>
>> Not a big deal, just seemed a little odd is all.
>
> Probably, but I'm not seeing it. Can you paste in what you're talking
> about?

% my $rowColor = 1;
<table class="associations">
% if (ENABLE_CATEGORY_BROWSER) {
<tr class="<% $rowColor++ % 2 == 0 ? "even" : "odd" %>">
<th><% $lang->maketext('Categories') %>:</th>
<td>
% my @cats = map { $_->get_uri } ( $story->get_primary_category,
$story->get_secondary_categories );
% $m->out(scalar(@cats) ? join('<br />', @cats) : $lang->maketext("No
categories defined."));
</td>
<td class="edit"><& '/widgets/profile/button.mc',
disp => $lang->maketext("Edit"),
widget => $widget,
cb => 'categories_cb',
button => 'pencil',
useTable => 0,
globalImage => 1 &></td>
</tr>
% }

david at kineticode

Mar 2, 2009, 12:25 PM

Post #15 of 22 (4026 views)
Permalink

Re: Keywords Permissions [In reply to]

On Mar 2, 2009, at 12:23 PM, Adrian Yee wrote:

>>> Not a big deal, just seemed a little odd is all.
>> Probably, but I'm not seeing it. Can you paste in what you're
>> talking about?
>
> % my $rowColor = 1;
> <table class="associations">
> % if (ENABLE_CATEGORY_BROWSER) {
> <tr class="<% $rowColor++ % 2 == 0 ? "even" : "odd" %>">
> <th><% $lang->maketext('Categories') %>:</th>
> <td>
> % my @cats = map { $_->get_uri } ( $story->get_primary_category,
> $story->get_secondary_categories );
> % $m->out(scalar(@cats) ? join('<br />', @cats) : $lang-
> >maketext("No categories defined."));
> </td>
> <td class="edit"><& '/widgets/profile/button.mc',
> disp => $lang->maketext("Edit"),
> widget => $widget,
> cb => 'categories_cb',
> button => 'pencil',
> useTable => 0,
> globalImage => 1 &></td>
> </tr>
> % }

No, that belongs there. If the category browser is enabled, the list
of categories goes into the "Associations" section along with
keywords. Otherwise, it gets its own section.

Best,

David

david at kineticode

Mar 2, 2009, 12:28 PM

Post #16 of 22 (4027 views)
Permalink

Re: Keywords Permissions [In reply to]

Quick review. Looks pretty good except for this bit:

On Mar 2, 2009, at 10:32 AM, Adrian Yee wrote:

> + if ($param->{new_keyword} and !
> chk_authz('Bric::Biz::Keyword', READ, 1)) {
> + throw_forbidden(maketext => [ 'You have not been
> granted permission to access keywords.' ]);
> + }
> foreach (@{ mk_aref($param->{new_keyword}) }) {
> next unless $_;
> my $kw = Bric::Biz::Keyword->lookup({ name => $_ });
> unless ($kw) {
> - $kw = Bric::Biz::Keyword->new({ name => $_ })->save;
> - log_event('keyword_new', $kw);
> + if (chk_authz('Bric::Biz::Keyword', CREATE, 1)) {
> + $kw = Bric::Biz::Keyword->new({ name => $_ })-
> >save;
> + log_event('keyword_new', $kw);
> + }
> + else {
> + throw_forbidden(
> + maketext => [
> + 'Could not create keyword, "[_1]", as
> you have not been granted permission to create new keywords.',
> + $_,
> + ],
> + );
> + }
> }

I think you have to check the READ permission where the keyword is
looked up, not above before you go through keywords, because a user
might have access to some keywords and not others. So it'd have to be
something like:

foreach (@{ mk_aref($param->{new_keyword}) }) {
next unless $_;
my $kw = Bric::Biz::Keyword->lookup({ name => $_ });
if ($kw) {
throw_forbidden(maketext => [ 'You have not been
granted permission to access keywords.' ])
unlesss chk_authz($kw, READ, 1)) {
} else {
if (chk_authz('Bric::Biz::Keyword', CREATE, 1)) {
$kw = Bric::Biz::Keyword->new({ name => $_ })-
>save;
log_event('keyword_new', $kw);
}
else {
throw_forbidden(
maketext => [
'Could not create keyword, "[_1]", as you
have not been granted permission to create new keywords.',
$_,
],
);
}
}

Thanks,

David

adrian at gossamer-threads

Mar 2, 2009, 12:43 PM

Post #17 of 22 (4028 views)
Permalink

Re: Keywords Permissions [In reply to]

> I think you have to check the READ permission where the keyword is
> looked up, not above before you go through keywords, because a user
> might have access to some keywords and not others. So it'd have to be
> something like:

Yeah, I was thinking about that today. I'll need to get all those
fixed. I also need to fix the category browser thing, since it was
hiding it as well when you didn't have permissions to access keywords.

So here's a question for you. What do we do with the keyword add field
in the case where a user only has READ permissions for select keywords?
Currently, it would hide it. Is there an easy way of knowing that the
user has permission to access to one or more keywords?

Adrian

david at kineticode

Mar 2, 2009, 1:08 PM

Post #18 of 22 (4025 views)
Permalink

Re: Keywords Permissions [In reply to]

On Mar 2, 2009, at 12:43 PM, Adrian Yee wrote:

>> I think you have to check the READ permission where the keyword is
>> looked up, not above before you go through keywords, because a user
>> might have access to some keywords and not others. So it'd have to
>> be something like:
>
> Yeah, I was thinking about that today. I'll need to get all those
> fixed. I also need to fix the category browser thing, since it was
> hiding it as well when you didn't have permissions to access keywords.

Right, that makes sense.

> So here's a question for you. What do we do with the keyword add
> field in the case where a user only has READ permissions for select
> keywords? Currently, it would hide it. Is there an easy way of
> knowing that the user has permission to access to one or more
> keywords?

Oh. I guess there's no reason to hide the keyword-adding field at all,
is there? Sorry, I should have thought of that before I suggested it!

Best,

David

adrian at gossamer-threads

Mar 5, 2009, 8:14 PM

Post #19 of 22 (4004 views)
Permalink

Re: Keywords Permissions [In reply to]

Okay, here's the latest patch. Updated in this patch:

- Check permissions of keyword autocomplete suggestions.
- Check permissions of all added keywords.
- Removed the code that removes the keyword add interface.
- For READ access errors, use the default error message (imho, fits
better than the message I was using in the last patch).

Adrian

Attachments:

keyword_perms.patch (14.8 KB)

david at kineticode

Mar 6, 2009, 3:01 PM

Post #20 of 22 (3993 views)
Permalink

Re: Keywords Permissions [In reply to]

On Mar 5, 2009, at 8:14 PM, Adrian Yee wrote:

> Okay, here's the latest patch. Updated in this patch:
>
> - Check permissions of keyword autocomplete suggestions.
> - Check permissions of all added keywords.
> - Removed the code that removes the keyword add interface.
> - For READ access errors, use the default error message (imho, fits
> better than the message I was using in the last patch).

Thanks, looks good to me. I'm not able to apply it, though:

% patch -p0 < ~/Desktop/kw.patch
patching file comp/widgets/profile/fast_add/autocomplete_keyword.html
patch: **** malformed patch at line 6: <ul>

So would you do the honors, once we get the commit bit to you?

Thanks,

David

adrian at gossamer-threads

Mar 6, 2009, 3:18 PM

Post #21 of 22 (3994 views)
Permalink

Re: Keywords Permissions [In reply to]

> % patch -p0 < ~/Desktop/kw.patch
> patching file comp/widgets/profile/fast_add/autocomplete_keyword.html
> patch: **** malformed patch at line 6: <ul>
>
> So would you do the honors, once we get the commit bit to you?

Weird breakage. Will commit when I get access. I guess I'll also need
to add an entry to bricolage/trunk/lib/Bric/Changes.pod as well.

Adrian

david at kineticode

Mar 6, 2009, 3:41 PM

Post #22 of 22 (4000 views)
Permalink

Re: Keywords Permissions [In reply to]

On Mar 6, 2009, at 3:18 PM, Adrian Yee wrote:

> Weird breakage. Will commit when I get access. I guess I'll also
> need to add an entry to bricolage/trunk/lib/Bric/Changes.pod as well.

Yes, please! And add your name to Bric::License and comp/widgets/help/
patchers.html

Best,

David

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads