What should be Reference type of 'Password' column in idempiere to hide the characters from client? - idempiere

I am using Idempiere 3.1.
In my table i have the password column.
I set it to the string.
In window it shows the value/character to user. What should be the reference type for password ? OR is there any other solution for it.

Go to Window -> Tab -> Field and mark Encrypted flag as true.
If you want to make it encrypted in database, you can use Column encryption option from Table And Column -> Column -> Run Process button.

Go to Window -> Tab -> Field and mark the Encrypted flag as true.
If you want to make it encrypted in the database, you can use
"Secure Content" flag. Don't forget to sync columns.

Related

Unable to see user list in search referenced field iDempiere-7.1

I have a window tab based on a table that has a foreign key reference to AD_User via ad_user_id. In Tables and Columns this column is given a 'Search' Reference with AD_User as the Reference Key.
When I open the tab with the ad_user_id field the search icon (green arrow) is displayed in the field for the user id but when the lookup is performed only the GardenAdmin logged on user, the one creating the record, is available to select. There are six users defined for GardenWorld, all of which are active.
What else needs to be done to get all the availible users on the selection list?
You can try setting -1 as the default for that new AD_User_ID field.
In iDempiere fields take defaults from different sources:
the first is the default defined in the column
if not set then it takes a user preference
if not set then it takes a global preference
this must be the case with your field, any field AD_User_ID will take the default defined in the context with ##AD_User_ID#. The same happens with AD_Role_ID and other fields that have a preference.
if global preference is not set then there are a lot of records marked as Default, and those are taken also as a global default
Note the order to get the defaults can be differently managed via the System Configurator key ZK_SEQ_DEFAULT_VALUE_PANEL

How to only make certain columns editable in a table in APEX ORACLE

I'm trying to make a interactive grid that allows users to update certain tables depending on the permission/privilege they have. Currently, there is an updatable table in APEX, but it allows for the user to edit every column. Is there a way to not allow the user to edit certain columns in APEX ORACLE? Thanks
Two simple options I can think of: navigate to column's properties and
set item type to "Display only", or
scroll down as set it to be "Read only" and specify some condition (the most obvious one is "Always")
You just need to go to Columns , expand, select the column that you want and set it to Display Only.
Wanted to post an answer here in case somebody else was looking for what I was when I found this.
If you want to make sure users can not change some columns but they can change others and that they can still add new rows.
You need to set each row you want to make not editable to read only when item is not null, type in the name of the row into the Item query and then also check that you want to do this for each row.

What determines default Interactive Report column layout in Oracle APEX 5?

I have an Interact Report page in Oracle APEX 5 that includes a SQL Query with ~10 columns or so. When I first load the report, the columns are in a certain order, and columns are set to Do Not Display (as seen under Actions -> Select Columns). The default order does not seem to match the order in which I list them in the SQL Query, nor does it use the order that is found in the Page Designer, under {Page Name} -> Regions -> Content Body -> {Interactive Report} -> Columns. I have two questions about the way columns are displayed in the Interact Report component:
What determines the default order of these columns?
What determines which columns are set to Do Not Display and those set to Display in Report?
Are those settings saved for each user?
First of all, you should probably take a good look at the documentation. Plenty of useful things. The main thing you're looking for in this case would be about saving interactive reports.
In short though.
When first having created the IR the columns will be in the same order as in the select statement.
Afterwards, there is no longer a relation between position in the select statement or the order of the columns as seen in page designer.
Instead, the initial order has been used to create an initial Primary Default report.
From this point on, column position and being hidden or display solely depends on the settings in the "Select Columns" menu.
If you want to alter the default offered to the end user, you'll have to run the page, alter the IR, and save your settings through Actions > Save Report and selecting Primary Default.
Settings saved for each user? Yes and no. End users will be offered the primary default at first. If multiple defaults are present the application will remember which one they have last been working on when coming back.
Users can also save private versions of reports, or public ones, if enabled. They can then edit the report settings, but these settings only affect their own report in that same session. If not saved, all changes they made settings-wise are lost and they'll be presented with the defaults again next time they log in. (or perform a reset themselves).
Unless you take all control away of course, by configuring the Actions menu of the IR.
I was hoping to edit saved reports in the Application Builder, but I guess this is not available (at least in 5.1 that I'm using).
This helped me:
SELECT FLOW_ID, PAGE_ID, REPORT_ALIAS, STATUS, IS_DEFAULT, DISPLAY_ROWS, REPORT_COLUMNS
FROM apex_050100.WWV_FLOW_WORKSHEET_RPTS
WHERE FLOW_ID = 101
AND page_id = 25
;
Then I edited that table updating columns list or other attributes of the saved report.

Trying to create test users through the Parse data browser fails

I am trying to add a set of PFUsers in the Data browser with emails, validated, passwords and usernames so that I can test a feature in my iOS app. But as I add the users, the passwords are lost and the validated field will not stay as 'YES'.
How can I add users for testing?
The process I've found success with is:
Adding a row.
Double clicking the appropriate cell to add a username then pressing enter.
Doing the same for password.
At the point it generates an ObjectId and I know the user has been stored.
In terms of a validated field, is that a column you added yourself or are you referring to the emailVerified column?
EDIT: In the case of emailVerified, you should be able to double click in the appropriate cell and it should present a drop-down of Boolean values that you can select.

Current version of data in database has changed since user initiated update process

I have a Master Detail form in my Oracle APEX application. When I am trying to update data in this form, I am getting below error.
Current version of data in database has changed since user initiated
update process. current row version identifier =
"26D0923D8A5144D6F483C2B9815D07D3" application row version identifier
= "1749BCD159359424E1EE00AC1C3E3FCB" (Row 1)
I have cleared browser cache and try to update. But it not worked.
How can I solve this?
I have experienced similar problem where my detail records set has timestamp fields. By default master detail wizard creates the timestamp fields as date picker type fields. If you set the date format on these, it would resolve the issue.
This blog post tries to address this issue on a Tabular Form (I know that's not what the original issue was with, but thought it might be related). It says the same as #sangam does below.
Short version: If you have an updated field that's timestamp datatype, you should set a date/time format.
http://apexbyg.blogspot.com/2015/05/tabular-form-bug.html
My tabular form has a field that's timestamp datatype, but I had already set a date format, so this didn't help me.
Here's another possibility, which I discovered was the case in my application.
That would be if the data the original checksum was calculated on is truly different than the pre-update checksum calculation, due to a design-flaw in your query!
In my application, the source for one of the updateable fields was COALESCE(name_calced, name_preferred). In the source table, the person's name could already be loaded in the record by an external process and we save it to one field - name_calced. But the end-user can enter a preferred name, which we wanted to save to the name_preferred field. We wanted to initially populate the displayed, updateable tabular form field with name_calced, if one existed, or name_preferred if the user had already provided a preferred name. Then they could change that value and save it back to the database.
I finally discovered that the Save action threw the error message if name_calced was non-null, but name_preferred was null. I realized that the initial checksum was calculated based on name_calced, but the pre-update checksum was based on name_preferred, so the application thought someone had changed the value in the background and showed the error message.
What I don't understand is how this problem didn't show up in the past 3 years the application has been running in production!
My solution is to make the field source only on name_preferred, which immediately solved this problem. I also think the back-end process will also get changed to pre-populate that table field from name_calced, so the user always sees the base value, if there is one.
I just had this issue myself. Now, I realize that tabular forms are deprecated at this time, but I have an application that was developed beforehand and still uses them. This issue occurred and I had to get one of our big guns at Oracle to help me out. I do a lot of DB work and a decent amount of Apex development but I'm more of a Java, WebLogic, etc guy, and I really couldn't figure this one out.
In my case, it turned out to be really simple. One of the columns in my tabular form was a hidden field, generated via a sub query. Being hidden, this column is not editable by the user and should not be part of the MRU update. I had the field set to "Hidden Column (saves states)" and setting its type to "Hidden Column" fixed the issue. So, this leads to sub queries being executed in such a way as to change the checksum for the overall query before hitting submit (save), causing the error.
For those who are continuing to troubleshoot this, look at your query for every field that you have specified and note which columns are editable in the tabular form. All other fields should be set in a way that makes them not save state so that they are not part of the update.
I had this error when I had two update processes processing on submit.
My solution was to add a condition to both processing steps. I had forgotten to do this when I made an additional process for Button A, but I never updated Button B to limit it's behaviors.
Navigation:
Processing -> Processes -> [Your Process Name] -> Server-side Condition -> When Button Pressed = [Your button Name]
In my case I had a column from a secondary table that was not set as Query Only and was being updated! The error would occur trying to save a column not in the table being updated. It took me half a day to figure it out (the column names were the same).
Set your Link column hidden to display only in the form.
Set "Send On Page Submit" to 'No' or disable the link column that is your primary key ( Rownum/rowid/id etc).
Hope it will work for you.
I have noticed this error comes when I was working Tabular Form and has disabled one of the form operations i.e. by setting server-side condition to "Never" for add, apply changes (submit) buttons
When I have restored back to its original state, it worked as expected.
In case you have to hide Add/Update button, use some other option.
https://compknowledgebase.blogspot.com/2018/12/oracle-apex-error-current-version-of.html

Resources