AX 2009: Can't find "SalesCreateReleaseOrderLineTmp" Table - axapta

I am a beginner in AX and I am trying to set access rights for some users and on a specific operation they get the error that they don't have access to the table SalesCreateReleaseOrderLineTmp. I have manually searched for this table in every category, but without success. I found on a website the full description of this table -> Order Lines - SalesCreateReleaseOrderLineTmp - ID: 995. I've search for the ID as well, but again no result. With admin rights everything is ok, but obviously not a solution.
Is there a fix location of this table and can anyone tell me where it is? :) Or is there any way to search for this table (by ID or name)?

I guess with
I have manually searched for this table in every category, but without
success
you mean you tried to find the table in the form for maintaining the user group permissions?
If so then this is due to the fact that temporary tables are hidden from that tree view as the class method SysDictTable.allowSecuritySetup is called from SysSecurity.expandSecurityKey while building the tree view and in this method there is - among other things - a check whether the table is temporary.
So essentially you have 3 options:
Give your permission group the desired access on the security key so that the group 'inherits' access to the table through it - downside of course could be to be too permissive but upside is better maintainability :)
Remove the security key on the temporary table as this in general is IMHO a wrong decision anyway. The application shouldn't restrict access to temporary tables (which are intrinsically scoped to the user session anyway) but rather force access checks in the code filling that table or even higher level processes.
Customize the code which builds the security tree view so that it includes temp. tables.
Try to apply the first option above that works for you as the first one does not need any application modification and the second one is only a simple property change which in my opinion is currently bad configured anyway. The last option should be the last resort.

Related

Can I make this simple app in App maker using calculated models for demonstration purposes?

I am new to Google App maker and I don't have a lot of experience with coding either (sorry :/). Since App maker is marked as low-coding app builder tool, I assumed it was not that hard to make a very simple app with it. However, for me it is.
I need to make a simple app for demonstrations purposes only (so Cloud SQL and other complex database solutions are not in my interest here). I want to make it using calculated models (correct me if I am wrong, calculated models are just temporary solutions, since apps need to have like real databases to be fully functional?).
My app is basically made of 2 datas: 1) Employees and 2) Departments
-> Fields for "Employees" are: First name, Last name and Department.
-> Field for "Departments" is just Department name.
My app is supposed to look like this:
1st page: Table with current employees that has a button to add new employee,
2st page: Table with all department names (e.g. marketing, finance...) that has a button to add new department name,
3rd page: Form that opens when I click on add new employee button in which I can insert their first name, last name and from drop down menu choose department,
4th page: Form that opens when I click on add new department button in which I can insert new department name.
5th page: Form (or some other widget, not sure here) that has option to insert first and last name in order to find out what department that employee is assigned to.
I tried to make first 4 pages, but I end up with forms that I cannot insert anything into them. 5th page is still too much for me.
I hope you understand my struggles and if you know how to do it please share your knowledge. Thank you very much!
Calculated models are kind of like SQL views - they are not necessarily for temporary solutions. Every time you load a calculated model the script you write under that model's datasource is ran. That script usually loads data from an external source (I.e. grabbing stock prices from an API, loading data from an external SQL server, or generating random placeholder data).
You could use the cloud SQL models for this application that you are building - your table with all department names that is supposed to be displayed in the second page could just be a cloud SQL table with one single field for a department name.
I suggest you work through the example apps so you can get a better understanding of how the different components work. Here is a link to one for you to get started.
In short, you're going to create a few models to store information (I suggest using cloud SQL as the calculated models will require code whereas cloud SQL is more plug and play through app maker's bindings). Before you create any pages try to lay out how your databases will look as that will dictate how you set bindings or program your scripts.
Asking to completely make what is essentially a combination of the tutorials already provided by Google is pretty counter intuitive - you should ask more specific questions in regards to implementation.
As for App Maker being a low-code environment, that's only partially true. For very, very simple apps (think glorified forms) you will need only a couple lines of code and can probably do everything through drag-and-drop. However, anything more complicated than a simple form will almost certainly require a good chunk of actual code. There are plenty of resources online to learn Javascript.
You might want to try a google partner like AppSynergy for building stuff like this. It might be overkil for what you need (or maybe not if you intend to build a lot more stuff).

Risks to database and front-end coupling

I could not come up with any better title, after reading the question you can suggest a better one. Also you can suggest some better tags, I could not find web-development.
I am a student so I don't know the standard way to achieve the following issue.
I usually set the IDs of elements (div,span,tr,etc) according to the database primary key to reference it later easily.
For example on page having some rows of entries having their id set to the sno in the DB which is primary key and on click on any row checking the id and display the result from database using that id.
But I think its a bad idea as anyone can use Inspect Element or Dev Tools and change the ID.
What is the standard way to achieve this?
EDIT 1
I know that web browser wont enforce the security policy for me that's why I am asking for the standard way, or standard practices to use for this matter.
Anyway, you must assume that any request that comes to the back end may be forged, any any data sent to browser (visible or hidden) is public.
If you considere the the id are private (rather uncommon requirement), you could instead simply use a row order and keep on server session a table row_order <-> id.
If you simply want to ensure that the id are correct, just control them (server side) before updating the database, or at the time of the database write if you cannot control them before.
If you want to enforce any other policy (users have roles and depending on roles are allowed or not to update some values) all those controls have to be done server side.

Is it possible to create a database/table/view alias?

Let's say there is a database owned by someone else called theirdb with a very slow view named slowview. I have an app that queries this view regularly, but, because it takes too long, I want to materialize it to a table within a database that I own (mydb.materializedview).
Is there a way in Teradata to create an alias database object so that I can go like select * from theirdb.slowview, but actually be selecting from mydb.materializedview?
I need to do some rigorous testing against their view, but it's so slow that I hardly have time to test anything. The other option is to edit the code so that it reads from mydb.materializedview, but that is, unfortunately, not an option in this particular case.
Teradata does not allow for you to create aliases or symbolic links between objects.
If the object is fully qualified by database name and view name in the application your options are a little more restricted. You have have to create a backup of their view definition and them place your materialized table in the same database. This would obviously be best done during a planned application outage.
If the object is not fully qualified by database name and view name in the application and relies on a default database setting or application variable you have a little more flexibility. If all the work is done at a view level you can duplicate the environment in another database where you plan to have a materialized version of their slowview. Then by changing the users default database or application variable you can point it at the duplicate environment to complete your testing.
Additionally, you can try to cover (partially or fully) the query that makes up the slowview by using a join index. This allows you to leave the codebase as it is in the application but for queries that can be satisfied by the join index the optimizer will use the join index. Keep in mind that a join index does incur a cost as it is in essence a materialized version of the SQL which was used to construct it. This means additional IO and change management issues have to be taken in to account.
Lastly, you could try to create additional secondary or hash indexes on the objects within the slowview to improve it's performance.

Use ASP.NET Profile or not?

I need to store a few attributes of an authenticated user (I am using Membership API) and I need to make a choice between using Profiles or adding a new table with UserId as the PK. It appears that using Profiles is quick and needs less work upfront. However, I see the following downsides:
The profile values are squished into a single ntext column. At some point in the future, I will have SQL scripts that may update user's attributes. Querying a ntext column and trying to update a value sounds a little buggy to me.
If I choose to add a new user specific property and would like to assign a default for all the existing users, would it be possible?
My first impression has been that using profiles may cause maintainance headaches in the long run. Thoughts?
There was an article on MSDN (now on ASP.NET http://www.asp.net/downloads/sandbox/table-profile-provider-samples) that discusses how to make a Profile Table Provider. The idea is to store the Profile data in a table versus a row, making it easier to query with just SQL.
More onto that point, SQL Server 2005/2008 provides support for getting data via services and CLR code. You could conceivably access the Profile data via the API instead of the underlying tables directly.
As to point #2, you can set defaults to properties, and while this will not update other profiles immediately, the profile would be updated when next it is accessed.
Seems to me you have answered your own question. If your point 1 is likely to happen, then a SQL table is the only sensible option.
Check out this question...
ASP.NET built in user profile vs. old stile user class/tables
The first hint that the built-in profiles are badly designed is their use of delimited data in a relational database. There are a few cases that delimited data in a RDBMS makes sense, but this is definitely not one of them.
Unless you have a specific reason to use ASP.Net Profiles, I'd suggest you go with the separate tables instead.

In the context of an asp.net website, what's the most efficient way to check whether a User has access to a particular record?

I have a webpage that you pass in an id parameter (via a querystring), which it then uses to fetch data from a database. Typically, a user would navigate to this page from another page that lists only those records that the user has access to. However, if they go directly to the page by typing in the URL in the Address Bar, they can effectively view any record they like.
Eg. If they were to type something like http://localhost/TestSite/ClientAdmin/ManageLocation.aspx?LocationID=5 into their Address Bar, they can access the database record with the LocationID equal to five - even though they shouldn't have access to it.
Now, I could solve this by doing a database check every time the page is loaded to see whether the current user has access to the record they're trying to view. However this doesn't seem very efficient given that in most cases a user won't be trying to access a record that isn't theirs. Does anyone have a better suggestion?
Thanks.
Rather then doing an extra check when the page is loaded you could use an INNER JOIN and effectively return nothing if the access rights aren't there.
If all the indexes are there it shouldn't cost very much.
You could use Page.Request.UrlReferrer to see where they've come from, but it isn't a completely safe way of achieving this.
If each user has 'their own' data, that other users don't have access to, then it sounds like you may want to look at proper multitenancy - though that is often on a per-organisation basis rather than per-user:
http://en.wikipedia.org/wiki/Multitenancy

Resources