How to enforce individual custom views ?

Comments

• 14 Comments sorted by Votes Date Added
• carylt

  February 2006 Vote Up0Vote Down

  oh, and another question:
  
  record locking doesn't seem to be implemented.
  
  i've just done a quick test and two different users were allowed to edit the same account at the same time with no warning, and worse, they were both allowed to save the record (one obviously overwriting the other).
  
  how can that be?
  how do the people who have deployed this in a production environment can ensure consistency of data ?
  
  caryl
• mikefedyk

  February 2006 Vote Up0Vote Down

  you need to change your organization sharing settings for potential from public to private.
  
  please explore all of the settings available.
• carylt

  February 2006 Vote Up0Vote Down

  "mikefedyk&quot wrote:

  you need to change your organization sharing settings for potential from public to private.
  
  please explore all of the settings available.

  
  sure, will do.
  what about my second point, which i'm much more concerned about ?
  
  thx
  
  caryl
• Juao

  February 2006 Vote Up0Vote Down

  hello caryl
  

  "carylt&quot wrote:

  oh, and another question:
  
  record locking doesn't seem to be implemented.
  
  i've just done a quick test and two different users were allowed to edit the same account at the same time with no warning, and worse, they were both allowed to save the record (one obviously overwriting the other).
  
  how can that be?
  how do the people who have deployed this in a production environment can ensure consistency of data ?
  
  caryl

  
  since vtiger is a web based application, works with request->response communication model.
  
  the server cannot know when vtiger user close his browser (or connection get lost <!-- s:shock: --><img src="{smilies_path}/icon_eek.gif" alt=":shock:" title="shocked" /><!-- s:shock: --> ), in order to release lock in some record. only knows if user send this information to server.
  
  it is possible to do some timeout implementation to release locks... but there are problems with those timeouts... if it is very small, user cannot update the record... if it is too large, other users cannot get it fast...
  
  and about concurrency, if your server accepts more than one request at same time, it will get some synchronization issues...
  
  
  but how about external services and synchronization with other systems (web services, and direct access to database) ? <!-- s:? --><img src="{smilies_path}/icon_confused.gif" alt=":?" title="confused" /><!-- s:? -->
  
  afaik, most of the web applications doesn't have that feature... and even most erps and other enterprise softwares run without it.
  
  and imho, it doesn't worth the troubles...
  
  best regards
  joao oliveira
• dkmeans

  February 2006 Vote Up0Vote Down

  afaik, most of the web applications doesn't have that feature... and even most erps and other enterprise softwares run without it.

  
  i agree with that statement -- after lots of years in erp/crm desktops apps, it's just not as big an issue as it would appear. basically, this is set up to be "last saved wins"...
  
  you could i suppose have 3 sets of variables -- the "original" state, the "edited by me" state, and then before you hit save, compare the "original" against the database for anydatabases, and then alert the user -- this record was changed by user x. continue?"
  
  lot's of overhead with that too...thrashing the server to check for changes....even on things like order entry this makes sense....
• mikefedyk

  February 2006 Vote Up0Vote Down

  "dkmeans&quot wrote:

  afaik, most of the web applications doesn't have that feature... and even most erps and other enterprise softwares run without it.

  
  i agree with that statement -- after lots of years in erp/crm desktops apps, it's just not as big an issue as it would appear. basically, this is set up to be "last saved wins"...
  
  you could i suppose have 3 sets of variables -- the "original" state, the "edited by me" state, and then before you hit save, compare the "original" against the database for anydatabases, and then alert the user -- this record was changed by user x. continue?"
  
  lot's of overhead with that too...thrashing the server to check for changes....even on things like order entry this makes sense....

  
  not too much though. you go from:
  
  select
  ....
  update
  
  to this:
  select
  ....
  select
  update
  
  do you know if adodb handles anything for this?
• Juao

  February 2006 Vote Up0Vote Down

  well, i thought that the point was to lock one record.
  
  if the point is not to overwrite one change when a user is changing one record,
  
  it could be added one method like: computehash()
  this method would calculate one hash from one record of something...
  and stores it into $_session variable or hidden field in client browser while editing one record.
  
  this would avoid to copy all "old" values to user browser.
  
  regards
  joao oliveira
• mikefedyk

  February 2006 Vote Up0Vote Down

  "juao&quot wrote:

  this would avoid to copy all "old" values to user browser.

  
  why?
  
  selects are quite cheap and how would you have the hash generated? with stored procedures?
  
  we're not dealing with > 100kb of data from the database, we're looking at 1 to 5k max. that would take one second on a dial-up modem. i don't think that is a problem that needs fixing.
  
  jeffk posted on the dev list a solution with adodb so this is queued up for a fix now.
• carylt

  February 2006 Vote Up0Vote Down

  hi guys,
  
  different timezones: so i missed most of the discussion.
  so, to sum up, i disagree with the idea that record locking is not needed. this concept is at the base of all transaction based n-tier architectures and there is nothing inherently hard, difficult or expensive if implemented correctly.
  i have little experience with erp/crm's (vtiger or others), but even though, i find highly unlikely that a cxo will accept his company using a piece of software that could silently loose stock inventory or sales order data. i know mine won't and that is not up for debate.
  

  "juao&quot wrote:

  if the point is not to overwrite one change when a user is changing one record,
  
  it could be added one method like: computehash()
  this method would calculate one hash from one record of something...
  and stores it into $_session variable or hidden field in client browser while editing one record.

  
  exactly:
  whenever a record is updated (whether by a user or the system), it goes like

  ...
  getlock(record);
  if (computehash(readrecord(record)) == saved_hash)
      {
      updaterecord(newdata);
      }
  else
      {
      askuser("data has been modified: do you want to reload the data or abort?");
      ....
      }
  releaselock(record);
  

  
  

  "mikefedyk&quot wrote:

  
  we're not dealing with > 100kb of data from the database, we're looking at 1 to 5k max. that would take one second on a dial-up modem. i don't think that is a problem that needs fixing.

  
  i'm not sure i get what you're suggesting, are you talking about transferring data from the database to the webserver or all the way to the client broswer ?
  in my view, those checks should take place in the business-tier i.e. within the webserver process. if you want performance (and we all do) and to avoid issues such as lost browser connections, etc, you can't afford to carry any of that work in the client browser.
  

  "mikefedyk&quot wrote:

  jeffk posted on the dev list a solution with adodb so this is queued up for a fix now.

  
  do you have a link for those proposed changes ?
  
  
  
  rgds,
  
  caryl
• carylt

  February 2006 Vote Up0Vote Down

  iit seems i can't edit my previous message so i have to respond to myself. sorry. <!-- s:oops: --><img src="{smilies_path}/icon_redface.gif" alt=":oops:" title="embarassed" /><!-- s:oops: -->

  "carylt&quot wrote:

  ...
  getlock(record);
  if (computehash(readrecord(record)) == saved_hash)
      {
      updaterecord(newdata);
      }
  else
      {
      askuser("data has been modified: do you want to reload the data or abort?");
      ....
      }
  releaselock(record);
  

  
  actually, in the case we go back to the client broswer (reload or abort) the lock shouldn't be kept all that time.
  so, it's more like:

  ...
  getlock(record);
  if (computehash(readrecord(record)) == saved_hash)
      {
      updaterecord(newdata);
      releaselock(record);
      }
  else
      {
      releaselock(record);
      askuser("data has been modified: do you want to reload the data or abort?");
      ....
      }