Dear Gary,

Allow me to revert, not from the system administrator's position, but the 
user's point of view. and the user is the customer and therefore "always 
right". Of course, this does not mean that I am right in any way, but we 
have to take comments and wishes of the end users and act occasionally as a 
sounding board to perfect an already pretty perfect piece of software. This 
is where I come from with these requests, which I still regard a highly 
valid - from a user's perspective. How we as administrators and coders sort 
any such wishes out, is a different story altogether. see my comments below:

On Friday, 24 October 2014 18:59:20 UTC+3, Gary D Walborn wrote:
>
>  Chris,
>
>   I agree with you on some of these points.  Let me comment on each:
>   1) This can easily be done with the validation/normalization code that I 
> wrote.  It allows the user free-form entry and still validates and 
> normalizes the data.  I agree that proper widgets would be nicer.
>
The issue here is really, really usability. Not every eDMS admin is a 
coders or Python expert, and you said yourself that the normailsation code 
provided should probably not  been used on a rouitne basis - or did I get 
this wrong? I seriously think that metadata validation should be made as 
easy as pie.

>
>   2) This should actually be fairly easy now since Python functions can be 
> used for defaults.
>
 Have there been some recent changes? Any Python function? This is what I 
meant in (6). I have not had time to keep up with last week's changes - 
sorry.

>
>   3) That would be really handy but would require a GUI redesign.
>
Same as (1) - usability.  

>
>   4) I think we discussed this in earlier posts.  I see inherent problems 
> with metadata calculated from other metadata.  The order of evaluation and 
> dependencies can lead to unexpected results.  Perhaps a "display only" 
> field would help.  For example, the date is entered and a "display only" 
> field displays the entered data + 1 year, or 6 is entered into the field 
> and the display is "June".
>
Could we consider display or calculated data, only that do not need an 
extra table? Or, an extra table only as a last resort? 

>
>   5) Actions might be useful.  The example you give, however, can be done 
> with a simple index based on a Python function.
>
I think, again, usability is important. I also consider my previously made 
request for proper folders with group/user permissions that can separate 
whole departments  as part of this functionality; An index (which I created 
very early on) would, in fact, not shovel certain documents across to a 
different folder accessible by a different user group.

>
>   6) That would be very dangerous.  You can do something akin to this now 
> by way of acceptable functions and generators that provides some type of 
> protection.  (I did point out that there is currently a flaw in the logic 
> that allows arbitrary code to be executed.  I'd think that this will 
> probably go away when the "bug" is fixed.)
>
See  (2) - I might have missed something.

Thanks a lot, Gary.

>
> Gary W.
>
Chris 

>
>
> On Thursday, October 23, 2014 2:42:30 AM UTC-4, Christoph H. Larsen wrote:
>>
>> Dear All,
>> After a few discussion on various aspects related to metadata and their 
>> usability, allow me to summarize, and possibly draw up a wish list:
>>
>> (1) Dates and times are commonly used as metadata, and can be used for 
>> indexing and even scripting at a later stage. However, there is no standard 
>> entry format. Hence, proper data and time entry fields wouid be highly 
>> desirable, ideally for date only, time only, and date with time.
>>
>> (2) It would be nice, if the current user could be selected as default 
>> for instances, where a user has to be selected. Guess i am just missing 
>> something there.
>>
>> (3) Maybe all the usable variables could be made available via a pick 
>> list, and then spiced up with defaults or widget selections (dropdown, 
>> fixed default, etc.)
>>
>> (4) Number (3) and operators could then be used for easy evaluation. For 
>> instance, warranty certificates could be expired after a set period of time 
>> (entered as metadata)
>>
>> (5) Actions could even be added, like move expired warranty certificates 
>> into a different folder.
>>
>>
>> (6) Alternatively, possibly as an initial crutch, there could be a field 
>> that accepts python code, though this will reduce usability for 
>> unsuspecting users, if this remains the only choice of function entry.
>>
>> Any thoughts? 
>> Thanks a lot!
>>
>> Chris
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to