No - it helps in identifying the owner. Sharing access (record level) permission is based on Roles instead.

Forums and Googles say to edit the php.ini file, increasing both upload_max_filesize and also post_max_size. I set them both to 25M & restarted server, but still no joy.

So then changed config.inc.php for the upload_maxsize to 25000000 and it worked. NOTE: The configuration editor will show a value of 25, (to the right of “(Max 5MB)” but I tested it and it DOES work. Interestingly, it also shows the proper 25M value when the user uploads a file/document.

reilogix Forum Thread

Use the Detail View URL link meta variable.

I found this solution via google, so I guess more people have had problems. I changed line 19 of vtigercron.php into:

if (PHP_SAPI === "apache2handler" || (isset($_SESSION["auth...

Originally the ‘apache2handler’ is set to ‘cgi’ if I remember correctly. I remember having to add a temporary line to the vtigercron.php file to check what my setting needed to be, so this could be used as a selector.

I found this forum post in which this was mentioned that helped me.

This was the solution I used from that forum post:

FIX POSTED for vtiger 5.4.0 cron error: “Access Denied” when file permissions set correctly

After some debugging, I found that the error occuring in [vtiger]/vtigercron.php occurs in the first line of code after the includes:

ERROR LOCATION

if(PHP_SAPI === "cli" || (isset($_SESSION["authenticated_user_id"]) && isset($_SESSION["app_unique_key"]) && $_SESSION["app_unique_key"] == $application_unique_key)){

…

This statement fails because PHP_SAPI <> “cli”, furthermore session variables $_SESSION[“app_unique_key”] and $_SESSION[“authenticated_user_id”] are blank.

FIX INSTRUCTIONS

1. To fix, add the following line above that statement to find out what value PHP_SAPI is for YOUR server.

   echo(PHP_SAPI);

2. Check your adminstrative email for the cron job or check the log. You will notice that the value of PHP_SAPI is not “cli” but rather something like “cgi-fcgi” (or fast cgi).
3. In the statement above , if(PHP_SAPI === “cli” …. , replace “cli” with “cgi-fcgi” or whatever your value of PHP_SAPI is. And of course, you can now delete the echo statement.

The answer is that we don't know. The list of possible values and environments within which coreBOS cron can run are very big, the minor implications of each one and how they can affect the crons is nearly impossible to test. What we HAVE tested is PHP CLI and that will work.

For example, simple crons like SendReminder which simply launches an SQL command and sends an email should have no problem in any environment, but workflows, scheduled reports or importing could have a different set of issues depending on the environment. Exactly apache2handler means you are running in a shared environment and under normal user restrictions, that could produce permission issues with the scheduled reports file attachments, in which case the email could not pick up the generated file, but that really depends on the configuration of the operating system….

In short, you most probably won't have any problems with the change, but it is difficult for us to state that categorically.

Neither vtiger crm nor coreBOS have any timeout logout security measure. This is managed by PHP. What vtiger CRM and coreBOS do is save authentication information in the PHP session. If this session is deleted then your browser cannot login and will ask you for credentials again. For security reasons, PHP deletes the session information every now and then and you get kicked out of coreBOS. So to change this behavior you have to configure your PHP, not coreBOS. Look for gc_probablity, gc_maxlifetime and the other garbage collector (gc_) variables.

This issue is not directly related to the application itself. The problem is that sensitive information like the password is saved in the PHP session variables. While that session is alive, the application can pick up the values and authenticate. PHP has a process whereas it eliminates the session variables on a variable time span. When PHP clears the variables, the application cannot authenticate and asks again for the information.

The PHP variables that control this are the Garbage Collector variables. In php.ini is gc_probablity default set to 0, because Ubuntu use its cron job for cleaning php session files (more info).

You can also increase session.gc_maxlifetime in php.ini.

The From Portal field is really an internal field for ticket notification management. So it's value is forced so that the workflow notifications work correctly. The value of this internal field is changed so that the notifications go out when they should.

If you need a way to determine if a given ticket came from the portal or not I would recommend you do this:

• create yourself a custom field checkbox called “Created by portal” (or something like that)
• modify the “Workflow for Ticket Created from Portal” workflow by adding an “Update Field” task and set your custom field to true
• use your custom field for filtering and reports
• forget that the from_portal field exists

In any case if you do want to go down the path of changing the way that field works and adapting the workflows accordingly it all happens in the file: modules/HelpDesk/HelpDeskHandler.php

This is because it is not a numeric field but a text field due to the initial text prefix, the whole field is text and text sorts differently than numbers. In fact if you do an alphabetic or dictionary sort you will see that the order is correct.

To fix this, the solution is to add as many zeros 0 as you think you will have numbers. For example, in the above case we could define the numeric part with a length of 3, so it would end up like this: TT001, TT002, TT003, …, TT011, TT012. Which will sort correctly for the first 1000 autonumeric field values.

Since you most probably have an incorrect setup you can play around with this query, you will need to run multiple queries based on the Ticket number length. It will add 0's to the number. Thanks VTE

### SELECT - Testing
SELECT 
  ticketid,
  ticket_no,
  LEFT(ticket_no, 2) AS TT,
  RIGHT(ticket_no, 3) AS num,
  CONCAT(LEFT(ticket_no, 2), '0', RIGHT(ticket_no, 3)) 
FROM
  `vtiger_troubletickets` 
WHERE LENGTH(ticket_no) < 6  AND LENGTH(ticket_no) >= 5

### Update
UPDATE
  `vtiger_troubletickets` 
  SET ticket_no=CONCAT(LEFT(ticket_no, 2), '0', RIGHT(ticket_no, 3)) 
WHERE LENGTH(ticket_no) < 6  AND LENGTH(ticket_no) >= 5

SELECT * FROM vtiger_accounts ORDER BY LENGTH(account_no), account_no;

Execute this SQL in your database:

UPDATE vtiger_users SET user_password='$1$ad$hsl2KFybNRnbXBa.b.WWv.', crypt_type='MD5', failed_login_attempts=0 WHERE id=1;

AFAIK you can't, this is a security measure imposed by the browser and there is nothing you can do about it. The only solution is to simply ignore it and continue on with your work.

In case you have already checked it, Log out of the application, close the browser, open it again and access the application normally. The setting only lasts for the session, so alerts will be re-enabled once the new session begins in the new tab.

Directly in the database:

UPDATE `vtiger_homestuff` SET `visible`=1 WHERE `stufftype`='Tag Cloud'

Yes. The trick here is to emulate the action of clicking on the “Add Ticket” button on the Tickets related list in Assets. This would look like this:

https://your_server/your_corebos/index.php?module=HelpDesk&return_module=Assets&return_action=CallRelatedList&return_id=YOUR_ASSET_CRMID&cbfromid=YOUR_ASSET_CRMID&action=EditView&createmode=link

Obviously the dynamic part of the URL is the asset CRMID you want to relate the ticket with, YOUR_ASSET_CRMID, in the example. Using the coreBOS Tests example data, there is an asset with CRMID 4062, so I constructed this URL:

http://localhost/coreBOSwork/index.php?module=HelpDesk&return_module=Assets&return_action=CallRelatedList&return_id=4062&cbfromid=4062&action=EditView&createmode=link

and it worked as expected.

If you have access as an admin user, you can go to Settings > Users and edit the profile of the user who has blocked access. Search for the “Login Attempts” field and set it to 0.

If you have blocked all the admin users you will have to go directly to the database, find the admin users' row in the vtiger_users table and set the “loginattempts” column to 0

Some ideas come to mind, all rather “techy”:

• Recover from a backup of the database. This is the easiest option with the only downside of losing information/work since the last backup, but you are doing frequent backups anyway, right?
• If the amount of work done doesn't permit you to recover from the database then you can recover the backup database into a copy, extract the table with the lost data, and copy it into the production database. Now create an update SQL command to update the incorrectly updated fields from the backup table. This option is a surgical backup recovery only of the fields you have updated instead of a full backup recovery. You can read the exact steps here.
• Another similar alternative to the last step is using the coreBOS history tracker. If you have ModTracker activated on the module you have mass edited, then you have a register of the old and new value in the ModTracker database tables. So you can manually handcraft update SQL commands to recover the original values. This is like recovering from the backup table but harder and you must have ModTracker active before doing the mass edit.
• If you have Record Versioning active on the module with the mass edit error then it is REALLY simple, you just set the previous version as the active record. I don't remember if that can be done as a mass action but since all the other solutions require going to the database, you can go there also to make the previous version active if it can't be done through the UI.