Clarity

This is in v13.3.

I have an NSQL query which is retrieving project data and has the standard security clause

@WHERE:SECURITY:PROJECT:i.id@

in it.

In preview this turns into looking records in odfsec_project_v2.

There is a particular project which does not come on the portlet and it turned out that it does have are a single record in that view while projects that do come have records for assuming all the users who have rights over it.

The project was created quite normally and I cannot find a reason why it differs from the others.

What might be preventing this project from having records in that view?

The project is active and not a template and it is not flagged for purging.

Can your user "see" the project in the application OK? Sounds just like permissions have not been set up in the same way as your other projects.

Would assume that the "Full View" against the project access doesn't show the user either.

Its not a case of "last_updated_by = -99" is it; that makes stuff go weird ?

--

When you preview that @WHERE:SECURITY:PROJECT:i.id@ clause, it only gets generated with the user_id of "1", if you are debugging then you need to replace the "1" by the user_id of the user that you have the problems with. Having said that though, the fact that you say the view only contains one record for the project is odd - do no users have "View All" rights as that should always generate records in the view for any project.

Technical problems with rights sometimes happen - seem to recall a strange lock on the PRLOCK table causing issues once.

Depending on the structure of the query, the placement of the NSQL security join can influence results too.

Assume you ran this code

SELECT object_instance_id FROM odfsec_project_v2 WHERE user_id = USER_ID_HERE

Try running as different users, ideally an admin for starters to rule out first suggestion

Since I don't know your rights model and have no access to your system, it's a bit of a guess right now 

I'd start by taking a user with no result in that query and granting the "Project - Edit Management" right on the project missing, if that works then re-examine the rights model. In particular OBS.

One other thing to note is the full view is not correct in 13.3. It shows users users who don''t actually have access due to a problem with some of the rights.

Thanks guys.

Regarding the rights I and other users can see and edit the project in the GUI and that includes the user who created it.

So there must be more to it.

When I run

select * from odfsec_project_v2 where  (object_instance_id =  )

with the ID of the project in question I do not get any results, while another gives practically all the active users in the system.

Will keep digging.

I changed the joins in the query to what I believe are more correct and after that I see about a thousand more records including the ones I missed earlier. No change in security.  No change in the results of

select * from odfsec_project_v2 where  (object_instance_id =  )

So it remains unsolved to me how the standard security clause works.

If you can see the project in the application, but not get the results from the odfsec_project_v2 security view then this is because your application user has GLOBAL access rights to the project and that is not resolved in that 'v2' view.

You also need to look at the view odfsec_project_v - if the "user_id" is in that view then the user has global view (at least) access.

Thanks Dave_3.0 

If you say so. I do have global rights and so does the other user who was looking at the portlet. Modifying the joins made us both see the projects also in the portlet and not just elsewhere. So apparently it was not rights, but errors in the querz.

Looking at what

@WHERE:SECURITY:PROJECT:i.id@

turns in Preview might then not be quite accurate as it tefers only at the instance rights while behind the scenes global rights are also considered.

Yeah "preview" doesn't tell us the whole story I think - see this thread Inaccuracy with ODFSEC_PROJECT_V2 table and global rights 

But if your NSQL just contains the @WHERE:SECURITY:PROJECT:I.id@ NSQL construct (rather than trying to look at the views yourself) then this is all done for you by the application of course.

Thanks Dave_3.0, that sounds like the answer.