[Vtigercrm-developers] Discussion: Bug or Feature?

[Adam Heinz]

Earlier this year we finished our migration to Vtiger_Link-based context
menus and now have the ability to write custom permission checks for each
menu item, so it is straightforward to disable actions for a read-only
record.

That said, nothing would be stopping you from achieving a contrapositive
action -- you could easily create a new contract and assign it to the
account, unless you also added logic to filter your read-only objects from
related entity selection.


On Fri, Oct 18, 2013 at 9:48 AM, Alan Lord <alanslists at gmail.com> wrote:

> I was doing a small job for a customer the other day.
>
> They wanted certain Organisation records made read-only after some
> conditions were met.
>
> So we wrote a workflow to re-assign the records to a dummy user & role
> that had a special sharing rule to allow public, but read only, visibilty.
>
> That was fine - the Account record itself was visible but read only.
> *However*, the related list buttons like Add Event, or Select Contact etc.
> were still live and I could happily add new Contacts or Calendar activities
> to this record - which to my mind means it isn't really read-only.
>
> Thinking on this a bit more, it seems to me that this would be a rather a
> hard problem to crack.
>
> As an aside, the customer decided not to go down this route anyway because
> they didn't want the records re-assigned nor publicly visible. This is
> another permissions requirement that I don't think is possible either;
> making particular records read-only, without changing their owner? (Would
> be a nice feature, add a read-only flag to crmentity.)
>
> Cheers and have a good weekend.
>
>
> Al
>
> ______________________________**_________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20131018/2f8b9c6a/attachment-0001.html>